[PATCH v2 1/5] ld: fix segfault caused by untagged stub sections

[Christophe Lyon]

On Tue, 21 Oct 2025 at 12:48, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
>
> On Tue, 21 Oct 2025 at 12:28, Matthieu Longo <matthieu.longo@arm.com> wrote:
> >
> > On 2025-10-15 12:28, Christophe Lyon wrote:
> > > On Tue, 14 Oct 2025 at 12:47, Matthieu Longo <matthieu.longo@arm.com> wrote:
> > >>
> > >> In the case of non-contiguous memory regions, a far-call stub section
> > >> must be assigned to the memory of the section it was originally emitted
> > >> for. If the stub section does not fit, the section is marked as dropped,
> > >> and removed later. To emit a useful message to the user, however, a stub
> > >> section needs to be discernible from sections originating from input
> > >> objects.
> > >>
> > >> Previously [1], this distinction was made using the SEC_LINKER_CREATED
> > >> flag only in the AArch32 backend handler <arch>_add_stub_section. Other
> > >> backends that didn't set this flag on their stub sections skipped required
> > >> checks in ld/ldlang.c:size_input_section(). On AArch64, this caused the
> > >> linker to proceed into code paths that assumed output sections were set,
> > >> instead of reporting fatal errors, and ultimately led to a segmentation
> > >> fault.
> > >>
> > >> However, the SEC_LINKER_CREATED flag does not solely indicate that a
> > >> section was created by the linker. Its original meaning also meant that
> > >> the section should not be handled by the generic relocation code. Reusing
> > >> this flag to identify stub sections, while it appeared to fix the issue,
> > >> introduced unintended side effects. On PowerPC, for instance, it skipped
> > >> relocations present in the stubs and interpreted them as absolute
> > >> addresses.
> > >>
> > >> This patch proposes a new attribute 'veneer', indicating that a section
> > >> contains branch veneers. The attribute is set on AArch32, AArch64 and
> > >> PowerPC immediately after the creation of the stub section. Others
> > >> architectures are left unchanged, as they do not appear to support
> > >> non-contiguous memory regions (no tests were found to verify the fix).
> > >> Additionally, the diagnostic message was improved when a stub cannot be
> > >> placed in the same memory region as its referencing code.
> > >>
> > >
> > > Hi Matthieu,
> > >
> > > Thanks for this fix, and the time spent on analyzing the problem.
> > >
> > > I clearly missed the other implications of SEC_LINKER_CREATED when I
> > > originally implemented support for non-contiguous memory regions.
> > >
> > > Regarding other targets, I did not write additional tests, but I did
> > > run the testsuite on a long list of targets provided by Alan at that
> > > time:
> > > https://sourceware.org/pipermail/binutils/2020-February/110310.html
> > >
> > > Maybe you did that too? At least that would give confidence that there
> > > is no unexpected side-effect.
> > >
> > > FWIW, the approach LGTM.
> > > Thanks for making the error messages clearer ;-)
> > >
> > > Christophe
> > >
> >
> > Hi Christophe,
> >
> > I finished running the tests.
> >
> > --- ../build-dir-2/ROOT-test-result     2025-10-20 17:34:49.950810702 +0100
> > +++ HEAD-test-result    2025-10-20 18:17:55.031356787 +0100
> > @@ -2,7 +2,7 @@
> >   BUILD&TEST of aarch64-elf
> >   -------------
> >   Nothing to do for aarch64-elf !
> > -# of expected passes           858
> > +# of expected passes           868
> >   # of expected failures         5
> >   # of untested testcases                26
> >   # of unsupported tests         354
> > @@ -10,7 +10,7 @@
> >   BUILD&TEST of aarch64-linux
> >   -------------
> >   Nothing to do for aarch64-linux !
> > -# of expected passes           1151
> > +# of expected passes           1161
> >   # of expected failures         5
> >   # of untested testcases                26
> >   # of unsupported tests         180
> > @@ -18,8 +18,8 @@
> >   BUILD&TEST of aarch64_be-linux-gnu_ilp32
> >   -------------
> >   Nothing to do for aarch64_be-linux-gnu_ilp32 !
> > -# of expected passes           1024
> > -# of unexpected failures       120
> > +# of expected passes           1030
> > +# of unexpected failures       124
> >   # of expected failures         5
> >   # of untested testcases                26
> >   # of unsupported tests         185
> > The difference corresponds to the new tests added on AArch64 in patch 4/5.
> >
> > I found a same regression on 2 different architectures, all related to a
> > section that was silently dropped before whereas now it raises an error.
> > I fixed the failure by adapting the linker script and add those special
> > sections to /DISCARD/ (see below). This fix goes into patch 3/5.
> >
> > --- a/ld/testsuite/ld-elf/non-contiguous.ld
> > +++ b/ld/testsuite/ld-elf/non-contiguous.ld
> > @@ -14,17 +14,19 @@ SECTIONS
> >   {
> >      /* Ignore this target specific info in output comparison.  */
> >      /DISCARD/ : {
> > -             *(.ARM.attributes)
> > -            *(.ARC.attributes)
> > -            *(.riscv.attributes)
> > -            *(.c6xabi.attributes)
> > -            *(.trampolines)
> > -            *(.reginfo)
> > -            *(.note.renesas)
> > -            *(.MIPS.abiflags)
> > -            *(.MSP430.attributes)
> > -            *(.csky.attributes)
> > -            *(.gnu.attributes)
> > +     *(.ARM.attributes)
> > +     *(.ARC.attributes)
> > +     *(.riscv.attributes)
> > +     *(.c6xabi.attributes)
> > +     *(.trampolines)
> > +     *(.reginfo)
> > +     *(.note.renesas)
> > +     *(.note.spu_name)
> > +     *(.MIPS.abiflags)
> > +     *(.MIPS.options)
> > +     *(.MSP430.attributes)
> > +     *(.csky.attributes)
> > +     *(.gnu.attributes)
> >      }
> >
> So if I see correctly, you had to add *(.MIPS.options) ?
hmm I missed  *(.note.spu_name), but that's still OK for me ;-)

>
> >      .raml : /*AT ( ADDR (.text) + SIZEOF (.text) )*/
> >
> > Since there was no major issue found and the fixes are minor changes,
> > should I publish a new revision ?
>
> No that's OK for me, but I'm not a maintainer ;-)
>
> Thanks for testing!
>
> Christophe
>
> >
> > Matthieu