mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: Eleanor Bartle <eleanor@eleanor-nb.com>
Subject: Re: [musl] Care about Symbol Namespacing?
Date: Tue, 14 Nov 2023 16:35:06 +0100	[thread overview]
Message-ID: <ZVOTqq43gZD19xKP@voyager> (raw)
In-Reply-To: <b3c39abe-fecf-44cb-9283-27735bcd4701@app.fastmail.com>

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

  reply	other threads:[~2023-11-14 15:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14  2:32 Eleanor Bartle
2023-11-14  3:10 ` Rich Felker
2023-11-14  3:33   ` Eleanor Bartle
2023-11-14 15:35     ` Markus Wichmann [this message]
2023-11-15  6:11       ` Eleanor Bartle
2023-11-15 15:20         ` Rich Felker
2023-11-28  5:17           ` Fangrui Song
2023-11-29 13:45             ` Carlos O'Donell
2023-12-03 15:54               ` Fangrui Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZVOTqq43gZD19xKP@voyager \
    --to=nullplan@gmx.net \
    --cc=eleanor@eleanor-nb.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).