[PATCH] ld: Clear SEC_ALLOC for NOLOAD notes sections

[H.J. Lu]

On Thu, Mar 13, 2025 at 11:58 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.03.2025 02:02, H.J. Lu wrote:
> > On Thu, Mar 13, 2025 at 5:40 PM Alan Modra <amodra@gmail.com> wrote:
> >>
> >> On Thu, Mar 13, 2025 at 12:14:50PM -0700, H.J. Lu wrote:
> >>> If a note section is marked as NOLOAD, clear the SEC_ALLOC so that it
> >>> won't be treated as an SHF_ALLOC section, like a .bss section.
> >>
> >> Perhaps we should instead make NOLOAD consistent over all targets?
> >> That might not be possible, at least I thought so at the time I wrote
> >> that "Unfortunately.." comment, but it is nasty that NOLOAD behaves
> >> differently for ELF.
> >
> > Can we make the exception only for .bss sections, like
> >
> >      if (bfd_get_flavour (link_info.output_bfd) == bfd_target_elf_flavour
> >           && startswith (section->name, ".bss"))
> >         flags &= ~SEC_HAS_CONTENTS;
> >       else
> >         flags &= ~SEC_ALLOC;
>
> May I ask that we strive to avoid going from (just) section name for at
> least ELF, wherever possible? Something BSS-like may have effectively any
> section name; what matters is the NOBITS type. Same for note sections,
> where all that matters (or should I say "should matter") is that they're
> SHT_NOTE.
>
> As to the original patch - I guess alongside whatever final change there
> is going to be, the different behavior of NOLOAD then needs spelling out
> in the doc. That would be at least one predictable place where people can
> go look when being surprised by inconsistent behavior.
>

Here is the v2 patch:

https://sourceware.org/pipermail/binutils/2025-March/140002.html

-- 
H.J.