Proposal for new flag SHF_OS_NONCONFORMING_DISCARD

[Indu Bhagat]

Hi,

The specified behavior for SHF_OS_NONCONFORMING flag is that if the link
editor does not recognize the sh_type or sh_flags of the input section,
then it should reject the object file containing this section with an error.

I'd like to propose the addition of a new flag that complements the
existing SHF_OS_NONCONFORMING:

SHF_OS_NONCONFORMING_DISCARD (new flag)
This section requires special OS-specific processing (beyond the
standard linking rules) to avoid incorrect behavior. If this section has
either an sh_type value or contains sh_flags bits in the OS-specific
ranges for those fields, and a link editor processing this section does
not recognize those values, then the link editor should discard the
section without an error.

Such a flag will benefit those section types whose contents are not
amenable to simple concatenation. With the new flag, link editors that
are not aware of the specific section type will no longer have to resort
to either aborting the link or generating invalid data by concatenation
(concatenation is current guideline for handling unrecognized section
types with no SHF_OS_NONCONFORMING).

Thanks
Indu

[Fangrui Song]

Context: Indu wants the new section flag for SFrame, a replacement for Linux's ORC unwinder and a lightweight alternative to .eh_frame and .eh_frame_hdr for stack tracing (there is no personality routines, Language Specific Data Area (LSDA) information, or the ability to encode extra callee-saved registers.)

The pending SFrame support for linux-perf expects each module to contain a single indexed format for efficient runtime processing. 

While I believe for optimal portability, unwinders should support multiple-element structures within a .sframe section, I have a hard time convincing Indu

https://inbox.sourceware.org/binutils/CAN30aBF9r_D7Q1gaWXKpc0j_...@mail.gmail.com/T/#m0c11b1b571e5ef813f880df22ae64dcedd4259e1 (GNU Tools Cauldron SFrame talk notes). I've incorporated my replies to my blog post https://maskray.me/blog/2025-09-28-remarks-on-sframe

[Roland McGrath]

The SFrame situation seems quite analogous to .eh_frame: a compiler-produced part that can be concatenated, plus a linker-generated part that could not be produced that way.  There, the linker produces the additional section and phdr for it, and a linker that doesn't know about that just won't (and will simply blindly concatenate .eh_frame input sections without special processing).  I wonder why SFrame is not organized in the same way with a linker-generated index pointing into compiler-generated/linker-concatenated section data.

[Indu Bhagat]

On 2025-10-24 9:24 a.m., 'Roland McGrath' via Generic System V

Like .eh_frame, there is is one .sframe section for all .text* in an
input object. An SFrame unware linker will concatenate SFrame sections;
Now, if, say .text.X section is discarded at link time, linker will
issue an error ("error: relocation refers to a discarded section: X")
because the .sframe data for .text.X is not discarded. So SFrame-aware
handling in the linker becomes necessary. We debated on some ways to
resolve this (with an alternate layout, see below), but TL;DR is that it
affects the section size adversely.

Here is the current section layout. SFrame section consists of the
following (laid out in the following order):
- One SFrame Header (version, flags, ABI/arch identifier, number of
FDEs among other data)
- N SFrame FDEs (Fixed length entries for function-level metadata
like start PC, size of function etc.; One entry per function)
- M SFrame FREs (Variable length entries for stack trace data for
distinct ranges of PCs across all functions. Each function may have any
number of FREs.)
SFrame's index is inbuilt in the section. The SFrame FDEs are sorted on
start PCs if the accompanying flag SFRAME_F_FDE_SORTED is set in the
header. For ET_DYN, ET_EXEC, the linker creates the index and sets
SFRAME_F_FDE_SORTED.

The choice of one SFrame Header, and inbuilt FDE index helps reduce the
size of the section. An alternative where we split the section into
three different sections was discussed a bit here
https://sourceware.org/pipermail/binutils/2025-October/144753.html#:~:text=*%20Linker%2Dfriendly%20SFrame%20section%20layout).
Such an alternative layout, while _may_ be possible, it quite hurts
efficacy of the format in terms of size. Size is quite important for
SFrame users and its wider adoption.

For any alternative layout, getting rid of the header or duplicating the
header (into say each SFrame FRE data per function) is not preferable
either:
- SFrame header holds vital information like version, flags and other
provisions necessary for format evolution.
- It is wasteful to duplicate it for each set of function FREs (in
the new split section .sframe_info). It will bloat up the format
considerably.

Overall, it was not clear what (new) ELF provisions could be defined to
emit, say N SFrame headers if the M input .sframe sections with N
distinct versions are being linked together (e.g., when link-editor
needs to combine SFrame V3 and V4 sections). The solution needs to work
with linkers with and without linker scripts ideally.

So, we did not see a clear path to making the layout "linker-friendly"
without adversely affecting the efficacy of the format.

Lastly, linker-generated index cannot be optional in whatever solution
we adopt. SFrame aims to offer the solution for fast, reliable stack
tracing. Without an always-present index, the non-trivial task of
creating the index will fall on stack tracers; not desirable.

[1] SFrame wiki https://sourceware.org/binutils/wiki/sframe

[Roland McGrath]

IMHO the proper approach for the GC issue is to use section groups, so the .text section for a function and the .sframe section for that function are in a (non-COMDAT) section group together.  But that's only an answer to the GC issue while designing a format that is not deeply hostile to normal linker semantics, not to the desire to take a different approach for the header/index issue than the separately-generated header approach of .eh_frame_hdr paired with a base format (.eh_frame) that is inherently compatible with normal linker semantics.  I'd say that the lack of need for fundamental new linking semantics like you are now seeking is a pretty strong reason to prefer that design over the way you went.  But if you've settled on the format you want, then indeed there is no way to make generic ELF tools without explicit support for your format do what might be ideal for users.  You are frankly no more likely (maybe less) to get a new "generic" feature like this into any linkers or tools of interest than you are to just get your new format supported by them directly.  But good luck.

[Ali Bahrami]

I've never found SHF_OS_NONCONFORMING to be particularly
useful. I would rather not grow the collection of "what to do
when you don't know what you're doing" flags. It seems like
needless complexity, particularly as their use in any given
situation will continue long after its no longer needed.

I appreciate the concern for naive linkers that don't know
SFrame, and for not wanting them to produce garbage results,
but I think that is a temporary problem, and not worth
catering to. Either SFrame will be a success and in demand,
and link-editors will jump to provide the support, or it won't,
in which case it really doesn't matter what naive linkers do
with it. Either way, I'd rather not burden ELF with it.

gcc, and other open source compilers, already probe the
system they're being built on, including the link-editor
they target, to determine which features are supported, and
which are not. Isn't it simpler to just probe the link-editor
for SFrame support, and only generate those sections when
it's known that the link-editor will handle them properly?
I think this could easily just be a gcc configure option.
That eliminates the need for NONCONFORMING flags, and also
avoids generating bad output.

- Ali

> --
> You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com <mailto:generic-abi...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/generic-abi/92ea2f41-1538-4726-bc48-02b447891318n%40googlegroups.com <https://groups.google.com/d/msgid/generic-abi/92ea2f41-1538-4726-bc48-02b447891318n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Florian Weimer]

* Ali Bahrami:

> gcc, and other open source compilers, already probe the
> system they're being built on, including the link-editor
> they target, to determine which features are supported, and
> which are not. Isn't it simpler to just probe the link-editor
> for SFrame support, and only generate those sections when
> it's known that the link-editor will handle them properly?

The challenge is that when we start shipping object files as part of
the distribution that include new ELF sections, everyone will be
exposed to them. In general, we can manage to make our own linkers
compatible with that, but it's still desirable that the object files
remain compatible to some degree. If there are useless but dormant
output sections, that's probably okay. But something that looks like
valid data but isn't would be problematic, and so are outright linker
failures.

[Indu Bhagat]

On 2025-10-25 1:39 a.m., 'Roland McGrath' via Generic System V

Yes we thought about section groups and discussed it during GNU Tools
Cauldron, and it will work for the GC issue. However, the need of
keeping an explicit index generated at link-time would still require
linker awareness.

[Indu Bhagat]

On 2025-10-26 1:49 p.m., Ali Bahrami wrote:
>    I've never found SHF_OS_NONCONFORMING to be particularly
> useful. I would rather not grow the collection of "what to do
> when you don't know what you're doing" flags. It seems like
> needless complexity, particularly as their use in any given
> situation will continue long after its no longer needed.
>
> I appreciate the concern for naive linkers that don't know
> SFrame, and for not wanting them to produce garbage results,
> but I think that is a temporary problem, and not worth
> catering to. Either SFrame will be a success and in demand,
> and link-editors will jump to provide the support, or it won't,
> in which case it really doesn't matter what naive linkers do
> with it. Either way, I'd rather not burden ELF with it.
>

The flag is useful for any section requiring these semantics (SFrame
happens to be one of them).

> gcc, and other open source compilers, already probe the
> system they're being built on, including the link-editor
> they target, to determine which features are supported, and
> which are not. Isn't it simpler to just probe the link-editor
> for SFrame support, and only generate those sections when
> it's known that the link-editor will handle them properly?
> I think this could easily just be a gcc configure option.
> That eliminates the need for NONCONFORMING flags, and also
> avoids generating bad output.
>

Checking at gcc configure time does not eliminate the problem.
Users/packages are free to pick a linker of their choice at build time.

[Ali Bahrami]

I do see the issue (and live with it myself in other contexts
constantly), but it's a momentary concern. The link-editor needs to
be seeded with the ability before objects containing those sections
are delivered, or at the same time.

- Ali

[Ali Bahrami]

On 10/28/25 3:20 PM, Indu Bhagat wrote:
> On 2025-10-26 1:49 p.m., Ali Bahrami wrote:
>>     I've never found SHF_OS_NONCONFORMING to be particularly
>> useful. I would rather not grow the collection of "what to do
>> when you don't know what you're doing" flags. It seems like
>> needless complexity, particularly as their use in any given
>> situation will continue long after its no longer needed.
>>
>> I appreciate the concern for naive linkers that don't know
>> SFrame, and for not wanting them to produce garbage results,
>> but I think that is a temporary problem, and not worth
>> catering to. Either SFrame will be a success and in demand,
>> and link-editors will jump to provide the support, or it won't,
>> in which case it really doesn't matter what naive linkers do
>> with it. Either way, I'd rather not burden ELF with it.
>>
>
> The flag is useful for any section requiring these semantics (SFrame
> happens to be one of them).

I don't think there are many cases where those semantics
are really required. I've never seen SHF_OS_NONCONFORMING
used for anything. That's not a challenge to go find some
use to prove me wrong, but just an observation based on my
experience. ELF is decades old, the problem of introducing
new section types is not new, and the simplest answer is
almost always to manage the rollout, and get past it.

> Checking at gcc configure time does not eliminate the problem. Users/
> packages are free to pick a linker of their choice at build time.

Very few users do that. Mostly, they use the link-editor through the
compiler wrapper, and accept the link-editor that the compiler chooses.

Some sophisticated users may want to go ala carte, and as you say,
they're free to pick a linker of their choice that's different than
what the compiler defaults to.

- Since you're working on gcc, and communicating with
a major contributor to llvm, it seems that you'll have the
most obvious 2 link-editors covered in short order. That
really does cover 99.xxx% of the cases that matter.

- A user sophisticated enough to pick a link-editor other than
the obvious 2 (GNU and LLVM) is sophisticated enough to
know what they're doing, and not produce these sections
if their link-editor can't handle it. These folks can handle
a few bad SFrame links, until they decide to fix their link-editor
to handle it, or drop it. And, they pay attention to new
developments in binutils and llvm --- they'll see it coming.
Finally, what big important, can't fail for a moment,
packages are built in this mode?

- Adding new features to handle the case of not understanding
new features has a meta problem: Today, no link-editors understand
SHF_OS_NONCONFORMING_DISCARD. Even if we did agree to add it to
the gABI, it will be years before all linkers, not just GNU
and llvm, can be assumed to implement them. In the meantime,
you still have to confront the problem of what to do when
they don't.

I just don't see the need for permanent ELF features to solve
a temporary problem, however annoying it might be in the moment.
Success comes from making SFrame work well when its supported,
and not from investing in what happens when it isn't.

- Ali

[James Henderson]

I'm with Ali in that I don't think the new flag is needed or desirable. I actually think the section should simply have SHF_OS_NONCONFORMING, assuming it has a unique section type (and it certainly should have that because of the special link editor behaviour that is required). If a linker then sees the sframe sections while not supporting it, it'll generate an error and as far as I can tell, the user should be able to simply use objcopy or similar to remove the section(s) to allow them to continue linking. Yes, this is a workaround, but I think it's better than needing to add a new section flag for relatively short term benefit.

This is of course all under the assumption that the users who will encounter this case know enough that they can strip the offending section. I think this is likely for similar reasons to what Ali was saying about mixing toolchain components. I can think of the following cases where a user might encounter the new section type:

  * User is mixing and matching toolchain components. In this case, I expect the user will know they can use objcopy to remove the sections.

  * User is enabling sframe sections in the compiler, before their linker supports it. In this case, the user should just be able to disable it again (or use the objcopy workaround).

  * User is using a compiler that enables sframe by default. In this case, either the toolchain is misconfigured or the linker must already support sframe. Either way, not a problem that the gABI should worry about.

  * User has been given a prebuilt object or static library that contains sframe. Sharing objects between systems is generally risky unless the systems are using the same toolchain, in which case one of the earlier points should apply. It ultimately should be up to the producer to make sure they don't produce things their clients may not expect. Either that or the client is likely misusing the object/library and should know how to work with such things (i.e. they'll know how to use objcopy already).

Just my thoughts.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.

To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/generic-abi/a9c18ea6-8a6d-4ea5-b1c5-9060ccb3a112%40emvision.com.

[Indu Bhagat]

It is true that link-editors do have a clear path forward even without
the new flag SHF_OS_NONCONFORMING_DISCARD, either handle it or drop it.
Since SFrame (and other such non-concatenable sections will too) have
their own section type, link-editors should be able to check for the
specific section type and drop it rather than erroring out (until the
support in those link-editors is not a concern).

Such a process today may work for SHT_GNU_SFRAME, but tomorrow we do the
same for other such section types ...

Which one is a better path forward
- Allow a new flag SHF_OS_NONCONFORMING_DISCARD so link-editors once
conformant to that flag free up the distro/package maintainers' overhead
of handling each such section type, or
- Require link-editors to be fixed repeatedly with
section-type-specific checks for discarding. This must happen for each
new, non-concatenable section type until that specific linker is ready
to implement full support for it.

SHF_OS_NONCONFORMING_DISCARD, simply put is an ask for a more flexible
variant of SHF_OS_NONCONFORMING.