[RFC 25/28] [SFrame-V3] ld: add --no-sframe-info command line option

[Sterling Augustine]

I defer to others whether or not the option should exist, as I work in an
environment where this issue would not come up, so people closer to the
issue should probably evaluate it. Editing system linker scripts is pretty
annoying, and not all users will even have permission to do so. Partial
linker scripts with /DISCARD/ can work, but will generate a warning.

I would say that I would prefer to name it something like,
"--discard-sframe-sections" or whatever, which makes it sound much closer
to the linker script equivalent. `-no*` sounds like it is turning off an
option, and people generally expect that there will be a positive version
too, which won't work in this case.

On Mon, Dec 22, 2025 at 12:25 PM Indu Bhagat <indu.bhagat@oracle.com> wrote:

> On 12/22/25 7:27 AM, Jan Beulich wrote:
> > On 09.12.2025 10:07, Indu Bhagat via Binutils wrote:
> >> Add a new command line option `--no-sframe-info` to the linker. This
> option
> >> allows users to prevent the linker from generating .sframe sections,
> >> including the linker-generated (internal) SFrame sections for PLT
> entries.
> >>
> >> Previously, the existing `--no-ld-generated-unwind-info` option
> >> controlled whether (not just .eh_frame for PLT entries, but also) SFrame
> >> for PLT entries. This change decouples SFrame from other unwind formats
> >> (like .eh_frame), allowing for more control over the output binary's
> >> SFrame data.
> >>
> >> The option is added for architectures that currently support SFrame:
> >> AArch64, s390x, and x86_64.
> >>
> >> In a subsequent commit, we will tie this option with discard of all
> >> input .sframe sections.
> >
> > Note how the present field is "no_ld_generated_unwind_info", i.e.
> > affecting only linker generated data (if the name is to be trusted).
> > Discarding input .sframe sections gets in conflict with what a linker
> > script may be saying. While perhaps tolerable for the built-in ones,
> > I'm not sure this is desirable behavior at least for people's custom
> > scripts.
> >
>
> (Adding Sam and Augustine)
>
> The rationale for this option is: Consider the case when say, the distro
> is shipped with SFrame sections in the installed binaries/libraries. A
> user application using these installed libraries, but not enabling
> .sframe for itself just yet, will see an output .sframe corresponding to
> the pulled in libraries.  This is "partial" .sframe information for the
> application.  The option for user, if they want to turn off the .sframe
> section completely will be to edit the linker script; something that I
> thought may not be preferable ?
>
> Is editing the linker script for removing .sframe section from output
> acceptable and considered a well-received solution ?
>
> Thanks
> Indu
>
> >> TBD:
> >>    - For aarch64, is adding to both aarch64elf.sh and aarch64linux.sh
> >>      necessary?  The desired outcome is to allow the new command line
> for
> >>      aarch64 elf, amd64 elf, s390x elf only.  Confirm.
> >>
> >> bfd/
> >>      * elf64-s390.c (elf_s390_create_dynamic_sections): Use
> >>      no_ld_sframe_info to guard .sframe section creation.
> >>      * elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Likewise.
> >> include/
> >>      * bfdlink.h (struct bfd_link_info): Add no_ld_sframe_info bitfield.
> >> ld/
> >>      * ldlex.h (enum option_values): Add OPTION_NO_LD_SFRAME_INFO.
> >>      * lexsup.c (elf_sframe_list_options): New function.
> >>      (ld_list_options): Add sframe_info argument. Update callers.
> >>      * emulparams/sframe_info.sh: New file.
> >>      * emulparams/aarch64elf.sh: Source sframe_info.sh.
> >>      * emulparams/aarch64linux.sh: Likewise.
> >>      * emulparams/elf64_s390.sh: Likewise.
> >>      * emulparams/elf_x86_64.sh: Likewise.
> >>      * Makefile.am: Update to handle sframe_info.sh and new list
> options.
> >>      * configure.ac: Handle SFRAME_INFO target variable.
> >>      * Makefile.in: Regenerate.
> >>      * configure: Regenerate.
> >> ---
> >>   bfd/elf64-s390.c              |  2 +-
> >>   bfd/elfxx-x86.c               |  2 +-
> >>   include/bfdlink.h             |  4 ++++
> >>   ld/Makefile.am                |  3 ++-
> >>   ld/Makefile.in                |  4 +++-
> >>   ld/configure                  | 11 +++++++++--
> >>   ld/configure.ac               |  6 ++++++
> >>   ld/emulparams/aarch64elf.sh   |  1 +
> >>   ld/emulparams/aarch64linux.sh |  1 +
> >>   ld/emulparams/elf64_s390.sh   |  1 +
> >>   ld/emulparams/elf_x86_64.sh   |  1 +
> >>   ld/emulparams/sframe_info.sh  | 15 +++++++++++++++
> >>   ld/ldlex.h                    |  2 ++
> >>   ld/lexsup.c                   | 15 +++++++++++++--
> >>   14 files changed, 60 insertions(+), 8 deletions(-)
> >>   create mode 100644 ld/emulparams/sframe_info.sh
> >
> > Please can new files use dashes in preference to underscores in their
> names?
> >
>
> Done.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251222/c2a0c789/attachment.htm>