This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
PR12066
- From: Alan Modra <amodra at gmail dot com>
- To: binutils at sourceware dot org
- Date: Fri, 1 Oct 2010 17:50:31 +0930
- Subject: PR12066
- References: <20100810211654.GN6088@caradoc.them.org> <20100811022330.GD31102@bubble.grove.modra.org> <20100811210549.GT6088@caradoc.them.org> <20100812133552.GE31102@bubble.grove.modra.org> <20100812150746.GF31102@bubble.grove.modra.org> <mcrtymya7vy.fsf@google.com> <20100816150101.GM31102@bubble.grove.modra.org>
On Tue, Aug 17, 2010 at 12:31:01AM +0930, Alan Modra wrote:
> * NEWS: Mention change in linker script expression evaluation.
The PR 12066 test-cases assign lots of values to symbols, some of
which are addresses and some lengths or just plain numbers, then run
into trouble when they are all interpreted as absolute addresses. The
new expression evaluation scheme differentiates between numbers,
absolute addresses, and relative addresses. The trouble is that BFD
doesn't have a way to distinguish an absolute address from a plain
number, so assigning to a symbol then using it loses the difference
between a plain number and an address. I first developed a patch to
allow ld to do that (attached) then decided that a simpler approach
would work, and in fact is closer to the old ld expression evaluation.
Besides, the other patch caused a segfault in the xtensa relax_section
due to introducing an alias for bfd_abs_section, and I didn't want to
chase down all other potential problems.
PR ld/12066
* ldexp.c (fold_name): Treat absolute symbols as plain numbers.
* ld.texinfo (Expression Section): Don't say absolute symbols
are addresses.
Index: ld/ldexp.c
===================================================================
RCS file: /cvs/src/src/ld/ldexp.c,v
retrieving revision 1.86
diff -u -p -r1.86 ldexp.c
--- ld/ldexp.c 19 Aug 2010 05:51:49 -0000 1.86
+++ ld/ldexp.c 1 Oct 2010 02:34:55 -0000
@@ -553,6 +553,8 @@ fold_name (etree_type *tree)
" referenced in expression\n"),
tree->name.name);
}
+ else if (output_section == bfd_abs_section_ptr)
+ new_number (h->u.def.value + h->u.def.section->output_offset);
else
new_rel (h->u.def.value + h->u.def.section->output_offset,
output_section);
Index: ld/ld.texinfo
===================================================================
RCS file: /cvs/src/src/ld/ld.texinfo,v
retrieving revision 1.264
diff -u -p -r1.264 ld.texinfo
--- ld/ld.texinfo 16 Sep 2010 00:06:12 -0000 1.264
+++ ld/ld.texinfo 1 Oct 2010 02:56:29 -0000
@@ -5453,11 +5453,11 @@ value of a section relative symbol. On
symbol will retain the same value throughout any further link
operations.
-Some terms in linker expressions are addresses. This is true of all
-symbols and for builtin functions that return an address, such as
-@code{ADDR}, @code{LOADADDR}, @code{ORIGIN} and @code{SEGMENT_START}.
-Other terms are simply numbers, or are builtin functions that return a
-non-address value, such as @code{LENGTH}.
+Some terms in linker expressions are addresses. This is true of
+section relative symbols and for builtin functions that return an
+address, such as @code{ADDR}, @code{LOADADDR}, @code{ORIGIN} and
+@code{SEGMENT_START}. Other terms are simply numbers, or are builtin
+functions that return a non-address value, such as @code{LENGTH}.
When the linker evaluates an expression, the result depends on where
the expression is located in a linker script. Expressions appearing
--
Alan Modra
Australia Development Lab, IBM