From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9913 invoked from network); 14 Nov 2023 07:02:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Nov 2023 07:02:23 -0000 Received: (qmail 13806 invoked by uid 550); 14 Nov 2023 07:02:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14037 invoked from network); 14 Nov 2023 03:33:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eleanor-nb.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1699932816; x= 1700019216; bh=yVFxdN50OPtcJ4lLgj9bBejrkxEbf3FxFaBCpvHMHBQ=; b=E L+kc8AHwxFhw2bkY2JFWCnmqLuepMOj/JYDBQz8RYPlKPWtws61uFdkmkvXsAeR7 qt/2MVS5qXJiKb+zFQHU0c1BtevHzz8iUtdc9P3FaBLRfTXoFEB24AFRYXQaqnqm NirQFLUZkE6QHdGBwgtZpsAWYLXH0K42uEIB9TDd6QEe+Aagb41aABIKHdvcqgl+ zt4GUZBispEZuQ76YL0h3ENQCE7LPibWNwKPqUuX2Fe9VrMAInDSuBWowpUwiXaM 8mO92s2/7vwS9+qEiskaMr6iPiek7bzmZTMyIXljvHb+dbtVkwB9LsmFNuZpQevU WjnGXFTr5uS+dOTpp1fOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1699932816; x=1700019216; bh=yVFxdN50OPtcJ 4lLgj9bBejrkxEbf3FxFaBCpvHMHBQ=; b=OAngWtjTu85HLHo7AHfisRv2q01eo /SXkzVUqX4fuXXyeQtd2ongQESa/DgBi/BGIc6uRVDT6W7RITYJHHb+n5ZN5OBQJ pp6E54YUMe2hfiWrZRdqZeK6m9NzVACNFpMqmX3X+U2grQQNHDwbybD2mwOedCa4 Y2iUc0wtdGoLLkU0fl+rxriCAy9JzTMA4UItOCHH3BjCUikkmpMvTVquLioJaITP 7ob8NW5TBMTeP61jW6vO5PzUvNDrkMrt9AaMZZksIQrwk4VEdfjNQMrwJ5MwcytO 6xZSK+IFrT1IZxcbE5sdU/g4f/fuN68cTj/eZiOrh8LMVqbSIKrG8eZNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudefuddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgesrg dtreerreertdenucfhrhhomhepfdfglhgvrghnohhruceurghrthhlvgdfuceovghlvggr nhhorhesvghlvggrnhhorhdqnhgsrdgtohhmqeenucggtffrrghtthgvrhhnpeduuedttd evteffuddvkeehuddukeekhfelhefgleejuedttdehffdtteehffdvvdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegvlhgvrghnohhrsegvlh gvrghnohhrqdhnsgdrtghomh X-ME-Proxy: Feedback-ID: i5b0147a0:Fastmail X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c MIME-Version: 1.0 Message-Id: In-Reply-To: <20231114031026.GV4163@brightrain.aerifal.cx> References: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> <20231114031026.GV4163@brightrain.aerifal.cx> Date: Tue, 14 Nov 2023 14:33:15 +1100 From: "Eleanor Bartle" To: "Rich Felker" Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary=4f51b48c42934dccb6fc46f4208647d3 Subject: Re: [musl] Care about Symbol Namespacing? --4f51b48c42934dccb6fc46f4208647d3 Content-Type: text/plain 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. On Tue, 14 Nov 2023, at 14:10, Rich Felker wrote: > On Tue, Nov 14, 2023 at 01:32:02PM +1100, Eleanor Bartle 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? > > > > To be clear, I don't have such a proposal on hand, and it would take > > me a while to get one ready (and a while more to work out all the > > kinks I'll inevitably miss); I have the ghost of an idea involving > > components specifying interface names rather than filenames, which > > ld.so could then map to shared objects potentially non-injectively, > > but I don't know the fine details of implementation. This message is > > mainly to gauge if leadership is at all interested in the broad > > idea, to determine if even thinking about it is worth my time. > > The lack of this in ELF was by design, with the intent to give dynamic > linking semantics equivalent to static linking. This is also aligned > with the musl values of treating static linking as first-class (not > having functionality that doesn't work, or behaves wrong/differently, > in static-linked programs). I don't want to see something like this in > ELF, and it's not something I would support adding to musl even if > there were an ELF extension for it. > > As you noted, there are also concrete things that would have been > impossible (? at least difficult, and contingent on details) to fix > with such a system, like glibc moving symbols that wrongly ended up in > librt.so or libpthread.so to libc.so. > > Rich > --4f51b48c42934dccb6fc46f4208647d3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I see. So to ju= stify such a feature there'd need to be an analogous one for static arch= ives. Yeah, that's...ugly. I can begin to imagine such a mechanism but i= t twists everything out of shape. Not worth it.

=
On Tue, 14 Nov 2023, at 14:10, Rich Felker wrote:
On Tue, Nov 14, 2023 at 01:3= 2:02PM +1100, Eleanor Bartle wrote:
> [please cc]
> 
> ELF doesn't have a standard equiv= alent of Mach-O's Two-Level
> Namespace, but one can be= grafted on, as Solaris does with Direct
> Binding. I'v= e 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 wonder= ing is,
> is it worth thinking about a symbol namespaci= ng system that accounts
> for this? Would the robustnes= s benefits of such a system be worth
> the specificatio= n complexity?
> 
> To be clear, I= don't have such a proposal on hand, and it would take
>= ; me a while to get one ready (and a while more to work out all the
<= /div>
> kinks I'll inevitably miss); I have the ghost of an idea = involving
> components specifying interface names rathe= r than filenames, which
> ld.so could then map to share= d objects potentially non-injectively,
> but I don't kn= ow the fine details of implementation. This message is
>= ; mainly to gauge if leadership is at all interested in the broad
> idea, to determine if even thinking about it is worth my ti= me.

The lack of this in ELF was by design, = with the intent to give dynamic
linking semantics equivale= nt to static linking. This is also aligned
with the musl v= alues of treating static linking as first-class (not
havin= g functionality that doesn't work, or behaves wrong/differently,
in static-linked programs). I don't want to see something like th= is in
ELF, and it's not something I would support adding t= o musl even if
there were an ELF extension for it.

As you noted, there are also concrete things that = would have been
impossible (? at least difficult, and cont= ingent on details) to fix
with such a system, like glibc m= oving symbols that wrongly ended up in
librt.so or libpthr= ead.so to libc.so.

Rich

<= /div>

--4f51b48c42934dccb6fc46f4208647d3--