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.6 required=5.0 tests=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 1868 invoked from network); 14 Nov 2023 03:10:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Nov 2023 03:10:31 -0000 Received: (qmail 18215 invoked by uid 550); 14 Nov 2023 03:10:28 -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 18180 invoked from network); 14 Nov 2023 03:10:27 -0000 Date: Mon, 13 Nov 2023 22:10:26 -0500 From: Rich Felker To: Eleanor Bartle Cc: musl@lists.openwall.com Message-ID: <20231114031026.GV4163@brightrain.aerifal.cx> References: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Care about Symbol Namespacing? 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