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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31335 invoked from network); 14 Nov 2023 15:35:28 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Nov 2023 15:35:28 -0000 Received: (qmail 15596 invoked by uid 550); 14 Nov 2023 15:35:23 -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 15557 invoked from network); 14 Nov 2023 15:35:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1699976108; x=1700580908; i=nullplan@gmx.net; bh=htUHspXwWxwr1on91KrLJGRQGYh0donWxNpkha8haok=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=cCXqHdvKyBsupMkBUoOJOEilKDaJ7DI1oeYFOOKPu/yzR+1lU034PnFtKgFmP/o1 h31DcaBfe39I3owdb72Oih7bsJRoCjcsNlBffzLN8wMZA243mQgGYeoyYhLWMZH1p 8y3+jnt8iRNUVHIFUVejEGL/mtqTMWXeOsgsDX46E5SjlWsbhL8a6pTwe5zfvE3Xs 6T7Im4qfocjdxwswnFsbSBK24RdYzoW18X4hcDAy3SAVegExwPiOMCRbASrRRDmDF zS3N+p4VCwe6FwmeibCXn+GnOhYFiCbaQIi1o7BzkKXZCpGp39lGC/RLxwjaqn/4S Lq+hZixCETWuFNNXXQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Tue, 14 Nov 2023 16:35:06 +0100 From: Markus Wichmann To: musl@lists.openwall.com Cc: Eleanor Bartle Message-ID: References: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> <20231114031026.GV4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:16tBHHNoU47dUd0/hflDtz9X/shl0SmD2WJREz198PK1x6WzdNV VULx905nsWDxJmBDeL97OR1/U2zGdi3bUk+KgC69NAzd6sGV0U/nDHm7LgRmy1Z7VC6JhGD ggRPdl5uZpnMI51zOV8T8P7ugPhZXVt2gK8yAUXdLxOWABzqhQ3fsgrmi4C5uXxWHigSsme FguUm9a5Hm+QfPRd9728Q== UI-OutboundReport: notjunk:1;M01:P0:NlxbcQB1Dqg=;zstfN1HGXxREkknx1IiAbSFs52C ZbR8qjJz+gF+rkWDMg1YQGhmqzW8B2gGKaongKkGxcJ4FhrVbTfvhNPyFp+tVdyRL2lvwa6yU 5Q3897CQV0ZNoe9HLebsCyPEvKeW9v78C0ow3fzZ6X9Jr11pO7ae/JmuV1un1jRjvUgZbOMNW LZWyd3lOUEYqWzIaiU4BNFmjDlecEpB4gru7LNW5cLwb3p9LgEA2hF4LQ7JXr+Oxqjml18C4m 6TyaYjmduj7UJsxNwnpzN3P7hooah3QOVcN44ysN6ujiz7YGBKGQgpBfQUfQe7V5Ow5U1PpEp 6FfV6x/yVcQMgY5ODKI3iACVt8EQlFQUf6H4N3f36FqZkD3i4GDlp8MKzrXdLMzrvFqWPahHq hmq/Fa8ytS+CXMlVtM9MfsX2/xH5fPCxfpiCV9qRGD+G8vj5L7ujF1S1Ys2QN/LaTXuOGFGcO P4mYF1xySjMk+qXnoSNz0ZCmzxhwdq4gCl3/D7ltZhBJTI/kW4HDQjtJnmIEVPEj9M3MuRJPY TTYbfrTjLzjjZBub6mZrc9KBbU5Jzftl+tuRi7/o8K4mS6XT+bD5+cBqBxLA+2AFXGGvEF5Iq yWW8u6qm5zUnIMgvFbrrWrECLJGVHj/Nn6ewnao8/5uaCxJBhaBC/470kEiYw8eyc6gJP0ru8 7ETCTPUCgv9u0vGaC0hXtGAX3eEgHhkQ4oBdqVypLJEiO4Uyli/d1VQ2XYLROwskHhQTunXq/ PSiulAUrf+n/Ps9xd2HQGDXpqO0xoG4M+gwl75WwiYk5OsUFqWVHH3jPIeWTAsONh5hgLShuH vlk6FssHcOeI2fIEbSrP1YzrxaBX+HGhRRYQgULNePPIKA08EvIhdGs3etWreBSSt8k4i0n2w JT5Fg7MQfUgEKJ5UKBF1djnha8V7ioeggKN6E1oPmgD2Ek1ttI3i6frCODO8aZpJFEGRDj9N0 q7lxVA== Subject: Re: [musl] 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