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

[Christophe Lyon]

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) ?

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