This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Relative expressions and ASSERT


On Mon, 20 Dec 2010, Alan Modra wrote:

> I think this is a better solution, works on current binutils testsuite,
> the testcases in PR12066, and on kernel builds I tried.  You can
> even describe linker behaviour without too much embarassment.
> 
> I added an option to allow people to experiment with a consistent
> linker expression resolver by setting
>   __ld_compatibility = 221 ;
> somewhere in their linker scripts.  This treats numbers and absolute
> symbols as numbers everywhere, the most flexible arrangement since
> you can force a number to be an absolute address by using ABSOLUTE(),
> but you can't do the reverse.
> 
> 	* ld.texinfo (Expression Section): Describe treatment of numbers
> 	and absolute symbols.
> 	* ldemul.c (after_open_default): Look up __ld_compatibility.
> 	* ldexp.c (fold_name): Convert absolute symbols to numbers when
> 	inside output section definitions, or when __ld_compatibility >= 221.
> 	(exp_fold_tree_1): Convert numbers to absolute when not in output
> 	section definition and __ld_compatibility < 221.  Don't always
> 	convert values outside an output section definition to absolute.
> 	* ldexp.h (uses_defined): Comment.
> 	* ldlang.c (ld_compatibility): New variable.
> 	* ldlang.h (ld_compatibility): Declare.
> 	* emultempl/aix.em, * emultempl/armcoff.em, * emultempl/beos.em,
> 	* emultempl/elf32.em, * emultempl/genelf.em, * emultempl/lnk960.em,
> 	* emultempl/m68kcoff.em, * emultempl/mmo.em, * emultempl/pe.em,
> 	* emultempl/pep.em, * emultempl/sunos.em, * emultempl/z80.em: Call
> 	after_open_default from after_open function.

 This change broke the following case (ripped out of real-life code):

$ cat script.s # empty
$ cat script.ld
OUTPUT_ARCH(mips)
ENTRY(foobar)

MEMORY
{
  ram (rwx) : ORIGIN = 0x80000000 + 0x1000, LENGTH = 128M - 0x1000
}

PROVIDE(foobar = (bar - foo));

SECTIONS
{
  .rodata : ALIGN (4)
  {
    foo = .;
    LONG (0)
    LONG (1)
    LONG (2)
    LONG (3)
    LONG (4)
    LONG (5)
    bar = .;
  }
}
$ mips-sde-elf-as -o script.o script.s
$ mips-sde-elf-ld -efoobar -Tscript.ld -o script script.o

Before your change this correctly yielded the following symbols:

$ mips-sde-elf-objdump -t script

script:     file format elf32-tradbigmips

SYMBOL TABLE:
80001000 l    d  .rodata	00000000 .rodata
00000000 l    d  .reginfo	00000000 .reginfo
00000018 g       *ABS*	00000000 foobar
80001000 g       .rodata	00000000 foo
80001018 g       .rodata	00000000 bar

With your change in place it produces the following output:

$ mips-sde-elf-objdump -t script

script:     file format elf32-tradbigmips

SYMBOL TABLE:
80001000 l    d  .rodata	00000000 .rodata
00000000 l    d  .reginfo	00000000 .reginfo
80001018 g       .rodata	00000000 foobar
80001000 g       .rodata	00000000 foo
80001018 g       .rodata	00000000 bar

As you can see the subtraction operation was ignored together with the 
subtrahend (foo), and the minuend (bar) assigned to the symbol requested 
(foobar).

 Is that intended behaviour?  From your update to the manual I infer 
otherwise and it looks to me like a mishandled case that slipped through, 
but perhaps I'm missing something.  Either way I find it plain wrong that 
a difference of two symbols (both coming from/relative to the same 
section) yields a plain number in GAS, but not in an LD script.  Hmm...

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]