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.
