[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DS7PR12MB5765102CAA76FA19ADC3E993CBBCA@DS7PR12MB5765.namprd12.prod.outlook.com>
Date: Mon, 27 Nov 2023 21:17:04 -0800
From: Fangrui Song <i@...kray.me>
To: Eleanor Bartle <eleanor@...anor-nb.com>
Cc: musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>
Subject: Re: Care about Symbol Namespacing?
On Mon, Nov 13, 2023 at 7:02 PM Eleanor Bartle <eleanor@...anor-nb.com> wrote:
>
> [please cc]
>
> ELF doesn't have a standard equivalent of Mach-O's Two-Level Namespace, but one can be grafted on, as Solaris does with Direct Binding. I've inquired about this on IRC and the objections raised against it concern moving symbols between or coalescing shared objects without breaking dependent binaries. What I'm wondering is, is it worth thinking about a symbol namespacing system that accounts for this? Would the robustness benefits of such a system be worth the specification complexity?
I would be very interested in knowing the speedup of such a system.
Solaris folks can share performance numbers when direct bindings are
disabled, to give us some idea about how much we could expect.
I am also curious how much we can achieve by utilizing -Bsymbolic
family linker options:
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic
On Wed, Nov 15, 2023 at 7:20 AM Rich Felker <dalias@...c.org> wrote:
>
> On Wed, Nov 15, 2023 at 05:11:02PM +1100, Eleanor Bartle wrote:
> > That's about it, yes. Though I will point out that Solaris supports
> > LD_PRELOAD just fine -- the preloads just need to be marked as such.
> > For calls between components there's really no way to structurally
> > prevent interposition.
> >
> > The benefit is faster inter-component symbol lookup, as well as
> > sanity in the face of an _accidental_ name collision. The tradeoff
> > is complexity of specification to support all existing use cases. If
> > the standard were being designed from scratch it might not be too
> > hard to accomplish cleanly; to graft on to an existing model is a
> > nightmare.
>
> If your intent is just to check for accidental name collision, you can
> do this with diagnostic tooling not runtime semantic changes. And this
> is what you want to know, and what I mean by static linking being
> first-class. Making accidental name collisions transparently work
> would make it so things break horribly when someone decides they want
> to static link, and you as the author don't realize this because you
> never tried static linking. What's better would be running a tool that
> basically just does ldd and looks for multiple definitions of the same
> symbol, and tells you "you've got something wrong! you need to fix
> that!"
>
> Rich
For name collision issues, I am thinking of an one-definition-rule
violation checking feature
https://maskray.me/blog/2022-11-13-odr-violation-detection#future-direction
---
Mach-O's Two-Level Namespace introduced several linker options to
enable symbol moving from one library to another.
https://blog.darlinghq.org/2018/07/mach-o-linking-and-loading-tricks.html
"To make that possible, Mach-O, ld, and dyld provide a few additional
features, namely, sub-libraries, reexporting symbols, and
meta-symbols."
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`.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
