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

[Matthieu Longo]

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

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

Matthieu