[PATCH v2] elf: Clear the SEC_ALLOC bit for NOLOAD note sections

[H.J. Lu]

On Fri, Mar 14, 2025 at 3:58 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Mar 14, 2025 at 3:50 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Fri, Mar 14, 2025 at 07:33:48AM -0700, H.J. Lu wrote:
> > > @@ -5965,7 +5965,10 @@ parentheses.  The following types are defined:
> > >
> > >  @item NOLOAD
> > >  The section should be marked as not loadable, so that it will not be
> > > -loaded into memory when the program is run.
> > > +loaded into memory when the program is run.  When generating an ELF
> > > +output file, the memory space is allocated for the section at run-time,
> > > +except for SHT_NOTE sections.  For other output files, no memory space
> > > +is allocated at run-time.
> >
> > Since we are documenting this, please say that the ELF behaviour is a
> > bug that may change to be consistent with non-ELF targets.  Patch OK
> > with that addition.
>
> This is what I am checking with
>
> @item NOLOAD
> The section should be marked as not loadable, so that it will not be
> loaded into memory when the program is run.  When generating an ELF
> output file, the memory space is allocated for the section at run-time,
> except for SHT_NOTE sections.  For other output files, no memory space
> is allocated at run-time.
>
> Note - the ELF behaviour is a bug that may change to be consistent
> with non-ELF targets.
>
> > I see https://sourceware.org/pipermail/binutils/2006-July/048170.html
> > after this was (likely accidentally) corrected, and the poster
> > obviously wanted the old buggy ELF behaviour.  Huh, NOLOAD is still
> > used in linux kernel scripts:
> > ./arch/arm/boot/compressed/vmlinux.lds.S:  .image_end (NOLOAD) : {
> >
> > Also, we have a number of tests that expect the current ELF behaviour.
> > ld-elf/noload-1, ld-elf-noload-2 and ld-scripts-output-section-types.
> > The last one even names a section .rom for expected bss-style
> > behaviour where it is clear to me that a ROM section ought to have the
> > non-ELF NOLOAD behaviour.  :-(  At least your new testcase actually
> > tests for good behaviour.
> >
> > --
> > Alan Modra
>

I am backporting it to 2.43/2.44 branches.


--
H.J.