[prev in list] [next in list] [prev in thread] [next in thread] 

List:       musl
Subject:    Re: [musl] Care about Symbol Namespacing?
From:       Fangrui Song <i () maskray ! me>
Date:       2023-12-03 15:54:45
Message-ID: DS7PR12MB576588D100D66D8801752107CB87A () DS7PR12MB5765 ! namprd12 ! prod ! outlook ! com
[Download RAW message or body]

On Wed, Nov 29, 2023 at 5:46 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 11/28/23 00:17, Fangrui Song wrote:
> > GNU symbol versioning is actually a system that provides the import
> > file information: vn_file. However, glibc rtld does not utilize
> > vn_file to speed up symbol searches. In addition,
> >
> >> https://maskray.me/blog/2020-11-26-all-about-symbol-versioning#version-script
> >> vn_file is essentially ignored for symbol search since glibc 2.30
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=24741 . Previously
> >> during relocation resolving, after an object failed to provide a
> >> match, if it matched vn_file, rtld would report an error `symbol %s
> >> version %s not defined in file %s with link time reference`.
>
> This change in glibc was intentional.

Yes. I agree that dropping the error is useful for symbol versioning.

> I agree with Rich here that static linking
> should be treated as a first class feature and glibc has moved towards ensuring
> that dynamic and static linking behaviour is more similar.

The similarity between archives and shared objects is a vague concept.
That said, I have tried to figure out the similar parts at
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#elf-interposition

* If a dynamic symbol is defined by multiple components, they don't conflict.
* For a symbol lookup (due to a relocation like
R_*_JUMP_SLOT/R_*_GLOB_DAT/absolute relocation/etc), the definition
from the first component wins.
* Definitions from subsequent components are overridden.

We can still add Solaris direct bindings style symbol search while
preserving these properties.

> The exception here is
> that in glibc the goal will be to give developers the option to disallow
> dlopen() from a statically linked application; thus providing the developer
> assurances that nothing else will be loaded (important when crossing namespace
> boundaries, particularly mount namespaces).
>
> --
> Cheers,
> Carlos.
>
[prev in list] [next in list] [prev in thread] [next in thread]