This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Relative expressions and ASSERT
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Daniel Jacobowitz <dan at codesourcery dot com>, binutils at sourceware dot org, Kazu Hirata <kazu at codesourcery dot com>
- Date: Thu, 16 Dec 2010 21:32:43 +1030
- Subject: Re: Relative expressions and ASSERT
- 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> <AANLkTim9rg4eQqsBraDKkYwE83mzmou5y10qhkRjhaPb@mail.gmail.com> <20100812233857.GG31102@bubble.grove.modra.org> <AANLkTinWgPGjkA26-KNgPyPSsePxtotok0+9Y+PEeLp0@mail.gmail.com>
On Wed, Dec 15, 2010 at 08:25:17PM -0800, H.J. Lu wrote:
> On Thu, Aug 12, 2010 at 4:38 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Thu, Aug 12, 2010 at 08:47:25AM -0700, H.J. Lu wrote:
> >> You can try the new linker on Linux kernel.
> >
> > An x86 2.6.35 kernel built without any differences.
> >
>
> It caused:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=12327
I was expecting this to cause some trouble. You can't avoid breaking
some linker scripts when you change the linker expression evaluation
rules (really, give it some rules rather than the adhoc mess that was
there before). I wonder if I should have gone a little further, and
removed the special case for expressions outside of an output section
definition. It's what I really wanted to do, but ran into a number of
testsuite failures in our own testsuite when I originally tried that.
Now that we differentiate between plain numbers and absolute symbols,
only one testcase needs adjusting.
So, if I commit this, scripts like the testcase below will need some
asjustment. On the other hand, sym1 = sym2 assignments should work
like they used to outside of an output section statement, fixing the
kernel problem and
frv-linux FAIL: FRV uClinux PIC relocs to weak undefined symbols, pie linking
frv-linux FAIL: FRV uClinux PIC relocs to weak undefined symbols, shared linking
How to people feel about this for 2.21.1?
ld/
* ldexp.c (exp_fold_tree_1): Don't make subexpressions absolute
when outside of an output section statement.
* ld.texinfo (Expression Section): Update description.
ld/testsuite/
* ld-scripts/align.t: Make ADDR absolute.
Index: ld/ldexp.c
===================================================================
RCS file: /cvs/src/src/ld/ldexp.c,v
retrieving revision 1.87
diff -u -p -r1.87 ldexp.c
--- ld/ldexp.c 1 Oct 2010 08:15:41 -0000 1.87
+++ ld/ldexp.c 16 Dec 2010 08:52:09 -0000
@@ -858,12 +858,6 @@ exp_fold_tree_1 (etree_type *tree)
memset (&expld.result, 0, sizeof (expld.result));
break;
}
-
- /* Any value not inside an output section statement is an
- absolute value. */
- if (expld.result.valid_p
- && expld.section == bfd_abs_section_ptr)
- make_abs ();
}
void
Index: ld/ld.texinfo
===================================================================
RCS file: /cvs/src/src/ld/ld.texinfo,v
retrieving revision 1.268
diff -u -p -r1.268 ld.texinfo
--- ld/ld.texinfo 15 Dec 2010 14:56:37 -0000 1.268
+++ ld/ld.texinfo 16 Dec 2010 08:52:59 -0000
@@ -5505,15 +5505,13 @@ address, such as @code{ADDR}, @code{LOAD
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
-outside an output section definitions are evaluated with all terms
-first being converted to absolute addresses before applying operators,
-and evaluate to an absolute address result. Expressions appearing
-inside an output section definition are evaluated with more complex
-rules, but the aim is to treat terms as relative addresses and produce
-a relative address result. In particular, an assignment of a number
-to a symbol results in a symbol relative to the output section with an
-offset given by the number. So, in the following simple example,
+the expression is located in a linker script. Outside of an output
+section definition, a result that is a number is treated as an
+absolute address. Inside an output section definition, a result that
+is a number is treated as a relative address. In particular, an
+assignment of a number to a symbol results in a symbol relative to the
+output section with an offset given by the number. So, in the
+following simple example,
@smallexample
@group
@@ -5537,9 +5535,8 @@ address 0x100 in the first two assignmen
@code{__data_start} are set to 0x10 relative to the @code{.data}
section in the second two assignments.
-For expressions appearing inside an output section definition
-involving numbers, relative addresses and absolute addresses, ld
-follows these rules to evaluate terms:
+For expressions involving numbers, relative addresses and absolute
+addresses, ld follows these rules to evaluate terms:
@itemize @bullet
@item
Index: ld/testsuite/ld-scripts/align.t
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/align.t,v
retrieving revision 1.1
diff -u -p -r1.1 align.t
--- ld/testsuite/ld-scripts/align.t 20 Feb 2004 15:31:10 -0000 1.1
+++ ld/testsuite/ld-scripts/align.t 16 Dec 2010 08:52:10 -0000
@@ -4,5 +4,5 @@ SECTIONS
.data ALIGN(0x40) : AT (ALIGN (LOADADDR (.text) + SIZEOF (.text), 0x80))
{}
ASSERT (LOADADDR(.data) == 0x80, "dyadic ALIGN broken")
- ASSERT (ADDR(.data) == 0x40, "monadic ALIGN broken")
+ ASSERT (ABSOLUTE(ADDR(.data)) == 0x40, "monadic ALIGN broken")
}
--
Alan Modra
Australia Development Lab, IBM