[PATCH] D118490: [lld][ELF] add .note sections from linker scripts as SHT_NOTE

Sat Jan 29 11:10:43 PST 2022

MaskRay added a comment.

In D118490#3281897 <https://reviews.llvm.org/D118490#3281897>, @bluca wrote:

> In D118490#3281539 <https://reviews.llvm.org/D118490#3281539>, @MaskRay wrote:
>
>> Non-SHF_ALLOC SHT_NOTE sections exists in the wild.
>>
>> - https://fedoraproject.org/wiki/Toolchain/Watermark#Proposed_Specification_for_non-loaded_notes
>> - ghc `ghcLinkInfoSectionName = ".debug-ghc-link-info"`
>>
>> I have created two patches to improve the propagating SHF_ALLOC situation.
>
> Thank you, I have tested them and can confirm this fixes the SHF_ALLOC problem. Updated this patch to remove the second part.
>
>> ---
>>
>> For the section type, I have filed a feature request ld: Customize output section type <https://sourceware.org/bugzilla/show_bug.cgi?id=28841>.
>> If an arbitrary output section type is too difficult, supporting just `SHT_NOTE` seems good enough.
>
> This would break backward compatibility in bfd, as suddenly linker scripts that produced SHT_NOTE sections would no longer do so without the option, so I don't think it is a viable option. And having it only for lld means there's source-level incompatibility with bfd, so that doesn't look like a viable option either.

I did not suggest that GNU ld dropped the special section notation.
I just suggest that new sections should explicitly specify the type and avoid magic names.
This can be used by more types other than SHT_NOTE.

>>> We have considered compiled objects and discarded that option as unfeasible. It's an absolute nightmare to even get a simple linker script to work reliably across 30.000 packages with a huge variation of different build systems and setups, across half a dozen different architectures. Having to also take care of an additional compilation steps means the whole endeavor will simply fail due to complications, so it is not an option.
>>
>> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects references https://github.com/systemd/package-notes/blob/main/hello.spec .
>> Can't we replace `-Wl,-dT,$PWD/notes.ld}` with an compiled .o?
>> Then it will work all linkers: GNU ld, gold, ld.lld, and mold, perhaps also the abandoned MCLinker.
>
> No, I already explained in the sentence you quoted, compiled objecs are not a realistic option.

I do not see why it is a complication.
The linker will add the section contributed by the relocatable object file to an appropriate place.
What problems did you find?
Does `.note.package` need to follow `.note.gnu.build-id`?

>>>> (I think communication can usually be improved by informing the involved parties early.
>>
>> An un-involved party may feel frustration, especially if you only started conversation with one camp and then essentially force the other camp to accept.)
>>
>>> I'm sorry if you feel frustrated, but I cannot change the past. Also, I assure you there was no conversation with the bfd 'camp' on this topic, so there's no 'favoritism' - I don't think I even mentioned this specification when I sent the READONLY patch, as it was completely orthogonal. Please understand that this is a complex effort with a huge number of moving parts (that has been discussed many times in many public places where anybody could chime in, including tech press articles and conferences), and the critical and really complicated pieces are elsewhere in the stack.
>>
>> (I did not want to make this review a blame place, but I have mentioned `READONLY` in two messages https://sourceware.org/pipermail/binutils/2021-May/116579.html https://sourceware.org/pipermail/binutils/2021-July/117492.html and I carefully ensured the patch author was on the To:/Cc: lines.
>> Perhaps I really should have kept more vigilance if I knew this going to be used in systemd, or, all Fedora packages?
>> I just raised https://sourceware.org/pipermail/binutils/2022-January/119537.html to question the error-prone `READONLY`
>> )
>
> As I have already shown, it is necessary. The note is read/write otherwise:
>
> [ 3] .note.package     NOTE             00000000000002e8  000002e8
>
>   0000000000000030  0000000000000000  WA       0     0     4
>
> and that breaks processing the note from core files. It needs to be read/only, like the build-id, and hence the required change in bfd to make it possible to do so.

As I explained in https://sourceware.org/pipermail/binutils/2022-January/119543.html ,
SHF_WRITE SHT_NOTE more likely suggests an unknown GNU ld bug (also ld.lld's when INSERT BEFORE is used).
It should be fixed instead of introducing READONLY.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118490/new/

https://reviews.llvm.org/D118490