[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVOTqq43gZD19xKP@voyager>
Date: Tue, 14 Nov 2023 16:35:06 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Eleanor Bartle <eleanor@...anor-nb.com>
Subject: Re: Care about Symbol Namespacing?
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
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.
