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

[i at maskray dot me]

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

--- Comment #3 from Fangrui Song <i at maskray dot me> ---
Hi Nick, sorry for my belated reply. I was on a trip.

> > 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.

The order issue can be fixed by postponing the effects of INSERT after regular
SECTIONS. Is it feasible?

> 
> > 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.

>From Debian Code Search,
https://codesearch.debian.net/search?q=%5B-%5DdT&literal=0 (-dT) has no result.
--default-script seems unused as well, so I think changing the behavior of -dT
probably does not matter.
Making -dT work in the presence of -T probably makes more sense.

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

-dT/--default-script seems unused (except the recent .note.package) and INSERT
is super rare as well. I think there are some changes which may be worth making
to make the behavior more reasonable and make the documentation more
explainable to a reader. The current behaviors may be a bit difficult to
describe in the documentation...

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