Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <lhuy0jxpfcu.fsf@oldenburg.str.redhat.com>
Date: Thu, 12 Mar 2026 10:27:29 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Jon Chesterfield <jonathanchesterfield@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Path for deploying clang on glibc systems

* Szabolcs Nagy:

> i think for a toolchain (2) with wrapper script should work:
>
> exec path/ld.so path/$(basename "$0") "$@"
>
> has a tiny wrapper overhead and may need --path ldpath setting.
> issues: if the binary tries to self re-exec, argv[0] is the
> basename not ld.so. tools like gdb, valgrind, qemu, ldd,...
> don't work on a wrapper script, needs manual tool ./ld.so binary,
> may not like that the main exe is loaded by ld.so, not the kernel.
> (should not be a big deal for a toolchain)

There could be an ld.so option for --argv0 to fix that at least.
However, /proc/self/exe will still be misleading.  I want to fix this in
glibc eventually, using PR_SET_MM_EXE_FILE, but it doesn't seem entirely
straightforward (for us at least) because we need to unmap the original
dynamic loader before issuing the system call.

Thanks,
Florian

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.