https://sourceware.org/bugzilla/show_bug.cgi?id=33830

--- Comment #1 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Indu Bhagat <[email protected]>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=11e0dbc08927f9d84ebbd98346d7016140049f5b

commit 11e0dbc08927f9d84ebbd98346d7016140049f5b
Author: Indu Bhagat <[email protected]>
Date:   Thu Jan 22 10:00:36 2026 +0200

    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 <[email protected]>

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to