ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs
GNU ld creates SFrame stack trace info for the PLT. For x86 the linker-
created .sframe section is created in setup_gnu_properties. For s390 it
is created in create_dynamic_sections. For both, the section data is
itself emitted a bit later in late_size_sections. Note that for aarch64 the
linker does not create .sframe for PLT yet.
Recall that a previous patch 832ca9ef670 uncoupled
--no-ld-generated-unwind-info from the linker-generated .sframe
sections. This means that the linker now generates .sframe section (for
.plt*) for the first input BFD enthusiatically even when none of the
input BFDs have any .sframe section, unless --discard-sframe is also
added. The issue is that these (unexpected) linker-generated .sframe
sections (on x86_64, and s390) may now trip the linking process, e.g.,
when using --orphan-handling=error together with a linker script that
treats .sframe differently than the default linker script.
https://sourceware.org/pipermail/binutils/2026-January/147826.html
Further, with SFrame sections to be soon marked KEEP for fixing
GC/SFrame (PR ld/32769), the presence of these linker generated SFrame
sections will also cause emission of an empty .sframe (for x86_64 and
s390x), even when all input bfd's have no .sframe section.
This patch avoids creation of .sframe for .plt* if none of the input
BFDs had any .sframe section. This then avoids creation of empty
.sframe in linked objects on x86_64 and s390x, when none of the inputs
have SFrame sections. This also fixes PR ld/33830.
For the code changes:
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
New testcases have (since the above Reviewed-by) been added. Since
--no-ld-generated-unwind-info is not supported on aarch64, add
target-specific ld tests. Additionally add a generic test (for all
targets that support SFrame) to ensure no output .sframe is generated if
users says no --gsframe or similar.
bfd/
PR ld/33830
* elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New
declaration.
* elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New
definition.
* elf64-s390.c (elf_s390_create_dynamic_sections): Do not
generate .sframe for .plt unconditionally.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Likewise.
ld/testsuite/
PR ld/33830
* ld-s390/no-sframe.ld: Linker script with no specification for
SFrame sections.
* ld-s390/s390.exp: Add new test.
* ld-s390/sframe-command-line-2.d: New testcase that uses
--no-ld-generated-unwind-info and a linker script that has no
specific rules for .sframe.
* ld-x86-64/no-sframe.ld: Likewise for x86_64.
* ld-x86-64/sframe-command-line-2.d: Likewise for x86_64.
* ld-x86-64/x86-64.exp: Add new test.
* ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in
output if no .sframe in input.
* ld-sframe/no-sframe.ld: Linker script with no specification
for SFrame sections.
* ld-sframe/test.s: Add new test.
ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs
GNU ld creates SFrame stack trace info for the PLT. For x86 the linker-
created .sframe section is created in setup_gnu_properties. For s390 it
is created in create_dynamic_sections. For both, the section data is
itself emitted a bit later in late_size_sections. Note that for aarch64 the
linker does not create .sframe for PLT yet.
Recall that a previous patch 832ca9ef670 uncoupled
--no-ld-generated-unwind-info from the linker-generated .sframe
sections. This means that the linker now generates .sframe section (for
.plt*) for the first input BFD enthusiatically even when none of the
input BFDs have any .sframe section, unless --discard-sframe is also
added. The issue is that these (unexpected) linker-generated .sframe
sections (on x86_64, and s390) may now trip the linking process, e.g.,
when using --orphan-handling=error together with a linker script that
treats .sframe differently than the default linker script.
https://sourceware.org/pipermail/binutils/2026-January/147826.html
Further, with SFrame sections to be soon marked KEEP for fixing
GC/SFrame (PR ld/32769), the presence of these linker generated SFrame
sections will also cause emission of an empty .sframe (for x86_64 and
s390x), even when all input bfd's have no .sframe section.
This patch avoids creation of .sframe for .plt* if none of the input
BFDs had any .sframe section. This then avoids creation of empty
.sframe in linked objects on x86_64 and s390x, when none of the inputs
have SFrame sections. This also fixes PR ld/33830.
For the code changes:
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
New testcases have (since the above Reviewed-by) been added. Since
--no-ld-generated-unwind-info is not supported on aarch64, add
target-specific ld tests. Additionally add a generic test (for all
targets that support SFrame) to ensure no output .sframe is generated if
users says no --gsframe or similar.
bfd/
PR ld/33830
* elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New
declaration.
* elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New
definition.
* elf64-s390.c (elf_s390_create_dynamic_sections): Do not
generate .sframe for .plt unconditionally.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Likewise.
ld/testsuite/
PR ld/33830
* ld-s390/no-sframe.ld: Linker script with no specification for
SFrame sections.
* ld-s390/s390.exp: Add new test.
* ld-s390/sframe-command-line-2.d: New testcase that uses
--no-ld-generated-unwind-info and a linker script that has no
specific rules for .sframe.
* ld-x86-64/no-sframe.ld: Likewise for x86_64.
* ld-x86-64/sframe-command-line-2.d: Likewise for x86_64.
* ld-x86-64/x86-64.exp: Add new test.
* ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in
output if no .sframe in input.
* ld-sframe/no-sframe.ld: Linker script with no specification
for SFrame sections.
* ld-sframe/test.s: Add new test.
bfd: include: sframe: fix PR ld/32789
Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data. For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.
The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
- doing relocatable link, and
- the input bfds contain multiple .text sections, say .text.hot,
.text.init, .text.unlikely etc.
For relocatable links, skip sorting the SFrame FDEs. Do not set
SFRAME_F_FDE_SORTED for relocatable links.
This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change. Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.
When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.
Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame. In this test, for object file generated
for pr32789-1a.c:
- the emitted SFrame FDEs by GAS are in the order of the .text* in the
input assembly (i.e., .text.init, .text, .text.exit)
- the emitted .text* sections by GAS are placed in the following order
.text, .text.init, .text.exit.
- GAS does not set SFRAME_F_FDE_SORTED, as expected.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.
bfd: include: sframe: fix PR ld/32789
Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data. For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.
The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
- doing relocatable link, and
- the input bfds contain multiple .text sections, say .text.hot,
.text.init, .text.unlikely etc.
For relocatable links, skip sorting the SFrame FDEs. Do not set
SFRAME_F_FDE_SORTED for relocatable links.
This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change. Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.
When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.
Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame. In this test, for object file generated
for pr32789-1a.c:
- the emitted SFrame FDEs by GAS are in the order of the .text* in the
input assembly (i.e., .text.init, .text, .text.exit)
- the emitted .text* sections by GAS are placed in the following order
.text, .text.init, .text.exit.
- GAS does not set SFRAME_F_FDE_SORTED, as expected.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.
bfd: include: sframe: fix PR ld/32789
Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data. For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.
The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
- doing relocatable link, and
- the input bfds contain multiple .text sections, say .text.hot,
.text.init, .text.unlikely etc.
For relocatable links, skip sorting the SFrame FDEs. Do not set
SFRAME_F_FDE_SORTED for relocatable links.
This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change. Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.
When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.
Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame. In this test, for object file generated
for pr32789-1a.c:
- the emitted SFrame FDEs by GAS are in the order of the .text* in the
input assembly (i.e., .text.init, .text, .text.exit)
- the emitted .text* sections by GAS are placed in the following order
.text, .text.init, .text.exit.
- GAS does not set SFRAME_F_FDE_SORTED, as expected.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.
bfd: include: sframe: fix PR ld/32789
Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data. For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.
The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
- doing relocatable link, and
- the input bfds contain multiple .text sections, say .text.hot,
.text.init, .text.unlikely etc.
For relocatable links, skip sorting the SFrame FDEs. Do not set
SFRAME_F_FDE_SORTED for relocatable links.
This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change. Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.
When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.
Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame. In this test, for object file generated
for pr32789-1a.c:
- the emitted SFrame FDEs by GAS are in the order of the .text* in the
input assembly (i.e., .text.init, .text, .text.exit)
- the emitted .text* sections by GAS are placed in the following order
.text, .text.init, .text.exit.
- GAS does not set SFRAME_F_FDE_SORTED, as expected.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.
ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs
GNU ld creates SFrame stack trace info for the PLT. For x86 the linker-
created .sframe section is created in setup_gnu_properties. For s390 it
is created in create_dynamic_sections. For both, the section data is
itself emitted a bit later in late_size_sections. Note that for aarch64 the
linker does not create .sframe for PLT yet.
Recall that a previous patch 832ca9ef670 uncoupled
--no-ld-generated-unwind-info from the linker-generated .sframe
sections. This means that the linker now generates .sframe section (for
.plt*) for the first input BFD enthusiatically even when none of the
input BFDs have any .sframe section, unless --discard-sframe is also
added. The issue is that these (unexpected) linker-generated .sframe
sections (on x86_64, and s390) may now trip the linking process, e.g.,
when using --orphan-handling=error together with a linker script that
treats .sframe differently than the default linker script.
https://sourceware.org/pipermail/binutils/2026-January/147826.html
Further, with SFrame sections to be soon marked KEEP for fixing
GC/SFrame (PR ld/32769), the presence of these linker generated SFrame
sections will also cause emission of an empty .sframe (for x86_64 and
s390x), even when all input bfd's have no .sframe section.
This patch avoids creation of .sframe for .plt* if none of the input
BFDs had any .sframe section. This then avoids creation of empty
.sframe in linked objects on x86_64 and s390x, when none of the inputs
have SFrame sections. This also fixes PR ld/33830.
For the code changes:
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
New testcases have (since the above Reviewed-by) been added. Since
--no-ld-generated-unwind-info is not supported on aarch64, add
target-specific ld tests. Additionally add a generic test (for all
targets that support SFrame) to ensure no output .sframe is generated if
users says no --gsframe or similar.
bfd/
PR ld/33830
* elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New
declaration.
* elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New
definition.
* elf64-s390.c (elf_s390_create_dynamic_sections): Do not
generate .sframe for .plt unconditionally.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Likewise.
ld/testsuite/
PR ld/33830
* ld-s390/no-sframe.ld: Linker script with no specification for
SFrame sections.
* ld-s390/s390.exp: Add new test.
* ld-s390/sframe-command-line-2.d: New testcase that uses
--no-ld-generated-unwind-info and a linker script that has no
specific rules for .sframe.
* ld-x86-64/no-sframe.ld: Likewise for x86_64.
* ld-x86-64/sframe-command-line-2.d: Likewise for x86_64.
* ld-x86-64/x86-64.exp: Add new test.
* ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in
output if no .sframe in input.
* ld-sframe/no-sframe.ld: Linker script with no specification
for SFrame sections.
* ld-sframe/test.s: Add new test.