[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Nov 2023 17:11:02 +1100
From: "Eleanor Bartle" <eleanor@...anor-nb.com>
To: "Markus Wichmann" <nullplan@....net>, musl@...ts.openwall.com
Subject: Re: Care about Symbol Namespacing?
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.
On Wed, 15 Nov 2023, at 02:35, Markus Wichmann wrote:
> Am Tue, Nov 14, 2023 at 02:33:15PM +1100 schrieb Eleanor Bartle:
> > I see. So to justify such a feature there'd need to be an analogous
> > one for static archives. Yeah, that's...ugly. I can begin to imagine
> > such a mechanism but it twists everything out of shape. Not worth it.
>
> Actually, no. The big overarching question is what you would hope to
> achieve with that feature. As I understand it, it is essentially what
> Windows does with the Import Directory, where you specify for each
> symbol what object it comes from.
>
> This would completely break linking semantics as of today. It's not that
> it isn't supported with static linking, it's that it would break
> existing workflows. Currently, in dynamically linked applications you
> can set LD_PRELOAD to overload symbols existing in otherwise loaded
> libraries, even libc symbols. This is useful to temporarily run an
> application with a different malloc() implementation, for example, or
> try out how much vectorized mem* functions would impact the run time.
> You can also use these approaches with static linking, but it would
> require re-linking each time.
>
> Adding such an extension would break this. Now libc symbols could only
> come from libc, and LD_PRELOAD wouldn't work anymore. And for no real
> benefit, or at least I can't see one.
>
> Ciao,
> Markus
>
Content of type "text/html" skipped
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.
