[Bug ld/28902] ld: `not found for insert` error has a weird ordering

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28902

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-02-28
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi Fangrui,  

> ld.bfd a.o -T insert-data.lds -T a.lds  # ok
> ld.bfd a.o -T a.lds -T insert-data.lds  # .data not found for insert
> 
> # Remark: The order is puzzling. If ld processes -T in order, one will
> expect that `-T a.lds -T insert-data.lds` works and the other order fails.

I have not dug deeply into this, but I would guess that this happens because
the script parser is stack based, so it pulls out and processes insert-data.lds
before a.lds.   But because semantic processing happens before syntactic
processing the INSERT in insert-data.lds has already stopped the default linker
script from being parsed, so the only possible definition of .data comes from
a.lds.

I expect that using multiple -T options combined with INSERT directives is a
rare thing, which is why no-one has noticed this odd behaviour before. 
Personally I think that the safest thing to do would be to just document the
behaviour, but not make any changes to the code.



> ld.bfd a.o -T insert-note.lds --build-id  # ok
> ld.bfd a.o -T a.lds -T insert-note.lds --build-id  # .note.gnu.build-id not
> found for insert

This makes sense.  The a.lds script does not define a .note.gnu.build-id
section, so there is nowhere for the INSERT AFTER in insert-note.lds to attach
to.

When a.lds is omitted the default linker script is used instead and this does
define a .note.gnu.build-id section, which is why the INSERT AFTER works.


> ld.bfd a.o -T a.lds -dT insert-note.lds --build-id  # ok
> 
> # Remark: Why -T fails while -dT works is puzzling. If you specify
> --verbose, the used linker script is exactly the same.

It seems that -T and -dT are incompatible.  In my tests it appears that the -dT
option is entirely ignored if -T is also used.  This is a bug, but I am
concerned that fixing it might break scripts which unknowingly rely upon this
behaviour.  So maybe it should be considered a documentation bug that the
incompatibility is not mentioned.

So overall I am inclined to think that these are both documentation bugs.  Do
you agree ?

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.