Solaris symbol visibilities in the new ELF specification

[Fangrui Song]

https://gabi.xinuos.com/elf/05-symtab.html
has been updated to include three new Solaris symbol visibilities (https://groups.google.com/g/generic-abi/c/AahK3BVmYWQ/ ).

Should this update also be reflected in the change history at https://gabi.xinuos.com/elf/c-history.html?

The three new attributes are:

> STV_EXPORTED
> This visibility attribute ensures that a symbol remains global. Unlike STV_DEFAULT symbols, whose visibility can be affected by other visibility requests, the STV_EXPORTED attribute ensures that the visibility of the symbol is not reduced by any other visibility request.
>
> STV_SINGLETON
> This visibility attribute is reserved to the psABI supplements. If implemented, it ensures that all references within a process bind to a single instance of the symbol definition.
>
> STV_ELIMINATE
> This visibility attribute is reserved to the psABI supplements. If implemented, it prevents the symbol from being written to the dynamic symbol table. Otherwise, it can be treated the same as STV_HIDDEN.

## STV_EXPORTED Utility

STV_EXPORTED appears useful for representing Windows `__declspec(dllexport)` semantics in ELF. For example:

  // a.c
  __declspec(dllexport) inline int inl() { return 42; }
  // b.c, c.c
  inline int inl() { return 42; }

`inl` will be exported in the linked output.

The constraining behavior (STV_PROTECTED < STV_HIDDEN < STV_INTERNAL < STV_EXPORTED) is unusual but logical-it allows a hypothetical `[[gnu::visibility("exported")]]` to export symbols even when using `#pragma GCC visibility("hidden")` globally (hiding both defined and undefined symbols).

Question:

- Is the omission of "This visibility attribute is reserved to the psABI supplements" for STV_EXPORTED intentional?
- When STV_EXPORTED is used, how is the symbol preemptitivity determined?

## psABI vs osABI Concerns

The specification states STV_SINGLETON and STV_ELIMINATE are "reserved to the psABI supplements," but this feels osABI to me.
Does Solaris set the two visibilities only with ELFOSABI_SOLARIS?

## STV_SINGLETON and STB_GNU_UNIQUE

STV_SINGLETON appears similar to `STB_GNU_UNIQUE`, which has caused significant issues:

- `STB_GNU_UNIQUE` has undesirable `DF_1_NODELETE` side effect, causing problems with C++ applications using `dlopen RTLD_LOCAL`
- Clang deliberately doesn't support `STB_GNU_UNIQUE` for good reasons

Nevertheless, it works for me as long as STV_SINGLETON is optional.

## STV_ELIMINATE

GNU ld-compatible linkers already exclude `STV_HIDDEN` symbols from `.dynsym`
Is STV_ELIMINATE intended to suppress `.symtab` entries when no relocations reference the symbol?

[Ali Bahrami]

On 9/27/25 00:57, Fangrui Song wrote:
> https://gabi.xinuos.com/elf/05-symtab.html
> has been updated to include three new Solaris symbol visibilities (https://groups.google.com/g/generic-abi/c/AahK3BVmYWQ/ ).
>
> Should this update also be reflected in the change history at https://gabi.xinuos.com/elf/c-history.html?

Yes, probably, but listing it as a 2025 addition will be
confusing, since these are not really new. The discussion happened
in 2007:

https://groups.google.com/g/generic-abi/c/AahK3BVmYWQ/m/oylW2Jkvpy0J

It was agreed to, but then, never made it into the actual
document. I'm not sure why, but it just fell through the
cracks somewhere. I noticed this omission some years later,
but the document had no maintainer by then, and so, there was
no avenue to fix it. I've been pinging Cary periodically
about it ever since he took on the task of updating the doc.
I'm happy to have it done, and I'm sure he's happy to know
I'll never bother him about it again.

Looking at our internal architecture records (PSARC/2007/559),
and at that old thread above, STV_EXPORTED is really an earlier
SCO invention that wasn't in the gABI. Rod was trying to add
SINGLETON and ELIMINATE, and noticed STV_EXPORTED while doing
due diligence and decided to be a good citizen and get it
documented as well. He said this on our internal architecture
review list:

> The proposal started with our requirement to add STV_SINGLETON
> and STV_ELIMINATE. However,, we found that SCO had already added
> to this public arena with STV_EXPORTED. We therefore intend to
> add three new visibilities.

See that old thread for more details about EXPORTED and its
history, as well as a discussion of the 2 actual Sun additions that
you might find useful.

> - Is the omission of "This visibility attribute is reserved to the psABI supplements" for STV_EXPORTED intentional?
> - When STV_EXPORTED is used, how is the symbol preemptitivity determined?

Sorry, I don't know the answer to either of these.

>
> ## psABI vs osABI Concerns
>
> The specification states STV_SINGLETON and STV_ELIMINATE are "reserved to the psABI supplements," but this feels osABI to me.
> Does Solaris set the two visibilities only with ELFOSABI_SOLARIS?

I see a mention of the psABI in that old thread, and these
sentences may originate there. I'm not really sure these
are psABI things, but stand ready to be corrected. Here
are my observations though:

- Solaris will use them on all platforms.

- I'm fairly sure no psABI mentions them.

- The visibility field doesn't have os or platform
parts, so doesn't that make everything there a
gABI defined matter? As such, I don't think their
use would require ELFOSABI_SOLARIS to be set.
Note though that any object using them probably
does other things that do cause ELFOSABI_SOLARIS
to get set, so the result is essentially as if
we did.

>
> ## STV_SINGLETON and STB_GNU_UNIQUE
>
> STV_SINGLETON appears similar to `STB_GNU_UNIQUE`, which has caused significant issues:
>
> - `STB_GNU_UNIQUE` has undesirable `DF_1_NODELETE` side effect, causing problems with C++ applications using `dlopen RTLD_LOCAL`
> - Clang deliberately doesn't support `STB_GNU_UNIQUE` for good reasons
>
> Nevertheless, it works for me as long as STV_SINGLETON is optional.

As far as I know, it is optional. The only likely use
would be by the Studio c++ compiler. Rod said this in
the PSARC case:

Indicates that only one instance of the symbol can be
bound to by any reference. This is a long standing C++
requirement that has relied upon interposition (but has
been broken by several linking techniques, such as symbol
scoping, -Bsymbolic and direct binding).

My memory is that direct binding was the real driver here.

>
> ## STV_ELIMINATE
>
> GNU ld-compatible linkers already exclude `STV_HIDDEN` symbols from `.dynsym`
> Is STV_ELIMINATE intended to suppress `.symtab` entries when no relocations reference the symbol?

ELIMINATE was motivated by the needs of DTrace, which
creates symbols that should be unconditionally erased
from final objects.

- Ali