* [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program @ 2022-04-05 3:18 Colin Cross 2022-04-05 3:57 ` Michael Forney 2022-04-05 4:43 ` Markus Wichmann 0 siblings, 2 replies; 9+ messages in thread From: Colin Cross @ 2022-04-05 3:18 UTC (permalink / raw) To: musl; +Cc: Colin Cross The glibc man page for dl_iterate_phdr states: The first object visited by callback is the main program. For the main program, the dlpi_name field will be an empty string. This is relied upon by the LLVM ASAN runtime: https://github.com/llvm/llvm-project/blob/72ec2f76396fe5de5397bfb898993fdb22e2b0da/compiler-rt/lib/asan/asan_linux.cpp#L135 Without this patch, running a binary that has been instrumented with ASAN fails with: ==4156919==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Use a constant empty string instead of the DSO name field for the first entry in the DSO list. --- This has come up previously on the mailing list at https://www.openwall.com/lists/musl/2018/05/28/1. ldso/dynlink.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ldso/dynlink.c b/ldso/dynlink.c index fd0d38e9..d2e22a0b 100644 --- a/ldso/dynlink.c +++ b/ldso/dynlink.c @@ -2323,12 +2323,15 @@ no_redir: int dl_iterate_phdr(int(*callback)(struct dl_phdr_info *info, size_t size, void *data), void *data) { + static const char* empty_string = ""; struct dso *current; struct dl_phdr_info info; int ret = 0; for(current = head; current;) { info.dlpi_addr = (uintptr_t)current->base; - info.dlpi_name = current->name; + /* glibc uses an empty string for the main program */ + info.dlpi_name = (current == head) ? empty_string : + current->name; info.dlpi_phdr = current->phdr; info.dlpi_phnum = current->phnum; info.dlpi_adds = gencnt; -- 2.35.1.1094.g7c7d902a7c-goog ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-05 3:18 [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program Colin Cross @ 2022-04-05 3:57 ` Michael Forney 2022-04-11 12:24 ` Jeffrey Walton 2022-04-05 4:43 ` Markus Wichmann 1 sibling, 1 reply; 9+ messages in thread From: Michael Forney @ 2022-04-05 3:57 UTC (permalink / raw) To: musl; +Cc: Colin Cross On 2022-04-04, Colin Cross <ccross@google.com> wrote: > The glibc man page for dl_iterate_phdr states: > The first object visited by callback is the main program. For the main > program, the > dlpi_name field will be an empty string. > > This is relied upon by the LLVM ASAN runtime: > https://github.com/llvm/llvm-project/blob/72ec2f76396fe5de5397bfb898993fdb22e2b0da/compiler-rt/lib/asan/asan_linux.cpp#L135 > > Without this patch, running a binary that has been instrumented with > ASAN fails with: > ==4156919==ASan runtime does not come first in initial library list; you > should either link runtime to your application or manually preload it with > LD_PRELOAD. > > Use a constant empty string instead of the DSO name field for the first > entry in the DSO list. I believe glibc is the exception here, not musl. When I looked at this, every other operating system I tried used the program name for the first object. I attempted to fix this generically here: https://reviews.llvm.org/D119515 Unfortunately, it seems to have caused some breakage and got reverted, but I wasn't able to reproduce it and nobody offered any pointers about how I might go about reproducing it. Any help moving forward with that would be appreciated. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-05 3:57 ` Michael Forney @ 2022-04-11 12:24 ` Jeffrey Walton 2022-04-11 12:42 ` Rich Felker 2022-04-11 12:46 ` Florian Weimer 0 siblings, 2 replies; 9+ messages in thread From: Jeffrey Walton @ 2022-04-11 12:24 UTC (permalink / raw) To: musl; +Cc: Colin Cross On Mon, Apr 4, 2022 at 11:57 PM Michael Forney <mforney@mforney.org> wrote: > > On 2022-04-04, Colin Cross <ccross@google.com> wrote: > > The glibc man page for dl_iterate_phdr states: > > The first object visited by callback is the main program. For the main > > program, the > > dlpi_name field will be an empty string. > > > > This is relied upon by the LLVM ASAN runtime: > > https://github.com/llvm/llvm-project/blob/72ec2f76396fe5de5397bfb898993fdb22e2b0da/compiler-rt/lib/asan/asan_linux.cpp#L135 > > > > Without this patch, running a binary that has been instrumented with > > ASAN fails with: > > ==4156919==ASan runtime does not come first in initial library list; you > > should either link runtime to your application or manually preload it with > > LD_PRELOAD. > > > > Use a constant empty string instead of the DSO name field for the first > > entry in the DSO list. > > I believe glibc is the exception here, not musl. When I looked at > this, every other operating system I tried used the program name for > the first object. I may be splitting hairs, but the dl_iterate_phdr(3) man page does not say a program is returned during the enumeration. It says shared objects are returned. $ man 3 dl_iterate_phdr DL_ITERATE_PHDR(3) Linux Programmer's Manual DL_ITERATE_PHDR(3) NAME dl_iterate_phdr - walk through list of shared objects SYNOPSIS #define _GNU_SOURCE /* See feature_test_macros(7) */ #include <link.h> int dl_iterate_phdr( int (*callback) (struct dl_phdr_info *info, size_t size, void *data), void *data); DESCRIPTION The dl_iterate_phdr() function allows an application to inquire at run time to find out which shared objects it has loaded, and the order in which they were loaded. The dl_iterate_phdr() function walks through the list of an application's shared objects and calls the function callback once for each object, until either all shared objects have been processed or callback returns a nonzero value. ... Jeff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-11 12:24 ` Jeffrey Walton @ 2022-04-11 12:42 ` Rich Felker 2022-04-11 14:03 ` Jeffrey Walton 2022-04-11 12:46 ` Florian Weimer 1 sibling, 1 reply; 9+ messages in thread From: Rich Felker @ 2022-04-11 12:42 UTC (permalink / raw) To: Jeffrey Walton; +Cc: musl, Colin Cross On Mon, Apr 11, 2022 at 08:24:21AM -0400, Jeffrey Walton wrote: > On Mon, Apr 4, 2022 at 11:57 PM Michael Forney <mforney@mforney.org> wrote: > > > > On 2022-04-04, Colin Cross <ccross@google.com> wrote: > > > The glibc man page for dl_iterate_phdr states: > > > The first object visited by callback is the main program. For the main > > > program, the > > > dlpi_name field will be an empty string. > > > > > > This is relied upon by the LLVM ASAN runtime: > > > https://github.com/llvm/llvm-project/blob/72ec2f76396fe5de5397bfb898993fdb22e2b0da/compiler-rt/lib/asan/asan_linux.cpp#L135 > > > > > > Without this patch, running a binary that has been instrumented with > > > ASAN fails with: > > > ==4156919==ASan runtime does not come first in initial library list; you > > > should either link runtime to your application or manually preload it with > > > LD_PRELOAD. > > > > > > Use a constant empty string instead of the DSO name field for the first > > > entry in the DSO list. > > > > I believe glibc is the exception here, not musl. When I looked at > > this, every other operating system I tried used the program name for > > the first object. > > I may be splitting hairs, but the dl_iterate_phdr(3) man page does not > say a program is returned during the enumeration. It says shared > objects are returned. You are. The intent, actual practice -- and absolute necessity for this function to serve its purpose, which includes admiting the implementation of exception handling -- is that it be included. And in this context, the (dynamic linked) program *is* a shared object. Rich ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-11 12:42 ` Rich Felker @ 2022-04-11 14:03 ` Jeffrey Walton 2022-04-11 14:58 ` Rich Felker 2022-04-11 15:52 ` Colin Cross 0 siblings, 2 replies; 9+ messages in thread From: Jeffrey Walton @ 2022-04-11 14:03 UTC (permalink / raw) To: Rich Felker; +Cc: musl, Colin Cross On Mon, Apr 11, 2022 at 8:42 AM Rich Felker <dalias@libc.org> wrote: > > On Mon, Apr 11, 2022 at 08:24:21AM -0400, Jeffrey Walton wrote: > > On Mon, Apr 4, 2022 at 11:57 PM Michael Forney <mforney@mforney.org> wrote: > > > > > > ... > > > > Use a constant empty string instead of the DSO name field for the first > > > > entry in the DSO list. > > > > > > I believe glibc is the exception here, not musl. When I looked at > > > this, every other operating system I tried used the program name for > > > the first object. > > > > I may be splitting hairs, but the dl_iterate_phdr(3) man page does not > > say a program is returned during the enumeration. It says shared > > objects are returned. > > You are. The intent, actual practice -- and absolute necessity for > this function to serve its purpose, which includes admiting the > implementation of exception handling -- is that it be included. And in > this context, the (dynamic linked) program *is* a shared object. I think you are conflating ET_DYN with a shared object. The presence of ET_DYN does not make a program a shared object, it merely means the object is relocatable (i.e., position independent code). Jeff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-11 14:03 ` Jeffrey Walton @ 2022-04-11 14:58 ` Rich Felker 2022-04-11 15:52 ` Colin Cross 1 sibling, 0 replies; 9+ messages in thread From: Rich Felker @ 2022-04-11 14:58 UTC (permalink / raw) To: Jeffrey Walton; +Cc: musl, Colin Cross On Mon, Apr 11, 2022 at 10:03:47AM -0400, Jeffrey Walton wrote: > On Mon, Apr 11, 2022 at 8:42 AM Rich Felker <dalias@libc.org> wrote: > > > > On Mon, Apr 11, 2022 at 08:24:21AM -0400, Jeffrey Walton wrote: > > > On Mon, Apr 4, 2022 at 11:57 PM Michael Forney <mforney@mforney.org> wrote: > > > > > > > > ... > > > > > Use a constant empty string instead of the DSO name field for the first > > > > > entry in the DSO list. > > > > > > > > I believe glibc is the exception here, not musl. When I looked at > > > > this, every other operating system I tried used the program name for > > > > the first object. > > > > > > I may be splitting hairs, but the dl_iterate_phdr(3) man page does not > > > say a program is returned during the enumeration. It says shared > > > objects are returned. > > > > You are. The intent, actual practice -- and absolute necessity for > > this function to serve its purpose, which includes admiting the > > implementation of exception handling -- is that it be included. And in > > this context, the (dynamic linked) program *is* a shared object. > > I think you are conflating ET_DYN with a shared object. The presence > of ET_DYN does not make a program a shared object, it merely means the > object is relocatable (i.e., position independent code). No, I'm not. What makes it a shared object is that it's one of the objects processed by the dynamic linker with a _DYNAMIC object, dynamic symbol table, dynamic relocation section, etc. whose symbols are shared with other shared objects at runtime. Rich ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-11 14:03 ` Jeffrey Walton 2022-04-11 14:58 ` Rich Felker @ 2022-04-11 15:52 ` Colin Cross 1 sibling, 0 replies; 9+ messages in thread From: Colin Cross @ 2022-04-11 15:52 UTC (permalink / raw) To: noloader; +Cc: Rich Felker, musl On Mon, Apr 11, 2022 at 7:03 AM Jeffrey Walton <noloader@gmail.com> wrote: > > On Mon, Apr 11, 2022 at 8:42 AM Rich Felker <dalias@libc.org> wrote: > > > > On Mon, Apr 11, 2022 at 08:24:21AM -0400, Jeffrey Walton wrote: > > > On Mon, Apr 4, 2022 at 11:57 PM Michael Forney <mforney@mforney.org> wrote: > > > > > > > > ... > > > > > Use a constant empty string instead of the DSO name field for the first > > > > > entry in the DSO list. > > > > > > > > I believe glibc is the exception here, not musl. When I looked at > > > > this, every other operating system I tried used the program name for > > > > the first object. > > > > > > I may be splitting hairs, but the dl_iterate_phdr(3) man page does not > > > say a program is returned during the enumeration. It says shared > > > objects are returned. > > > > You are. The intent, actual practice -- and absolute necessity for > > this function to serve its purpose, which includes admiting the > > implementation of exception handling -- is that it be included. And in > > this context, the (dynamic linked) program *is* a shared object. > > I think you are conflating ET_DYN with a shared object. The presence > of ET_DYN does not make a program a shared object, it merely means the > object is relocatable (i.e., position independent code). > > Jeff From further down in the same man page: The first object visited by callback is the main program. For the main program, the dlpi_name field will be an empty string. In any case, the motivation for this patch was for compatibility with LLVM's ASAN runtime, which has now been fixed to remove the empty name assumption by Michael's resubmitted patch at https://reviews.llvm.org/D119515, so this patch is no longer necessary. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-11 12:24 ` Jeffrey Walton 2022-04-11 12:42 ` Rich Felker @ 2022-04-11 12:46 ` Florian Weimer 1 sibling, 0 replies; 9+ messages in thread From: Florian Weimer @ 2022-04-11 12:46 UTC (permalink / raw) To: Jeffrey Walton; +Cc: musl, Colin Cross * Jeffrey Walton: > I may be splitting hairs, but the dl_iterate_phdr(3) man page does not > say a program is returned during the enumeration. It says shared > objects are returned. The libgcc unwinder assumes the main program is covered by the iteration. It won't work otherwise. Thanks, Florian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program 2022-04-05 3:18 [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program Colin Cross 2022-04-05 3:57 ` Michael Forney @ 2022-04-05 4:43 ` Markus Wichmann 1 sibling, 0 replies; 9+ messages in thread From: Markus Wichmann @ 2022-04-05 4:43 UTC (permalink / raw) To: musl; +Cc: Colin Cross On Mon, Apr 04, 2022 at 08:18:59PM -0700, Colin Cross wrote: > diff --git a/ldso/dynlink.c b/ldso/dynlink.c > index fd0d38e9..d2e22a0b 100644 > --- a/ldso/dynlink.c > +++ b/ldso/dynlink.c > @@ -2323,12 +2323,15 @@ no_redir: > > int dl_iterate_phdr(int(*callback)(struct dl_phdr_info *info, size_t size, void *data), void *data) > { > + static const char* empty_string = ""; > struct dso *current; > struct dl_phdr_info info; > int ret = 0; > for(current = head; current;) { > info.dlpi_addr = (uintptr_t)current->base; > - info.dlpi_name = current->name; > + /* glibc uses an empty string for the main program */ > + info.dlpi_name = (current == head) ? empty_string : > + current->name; > info.dlpi_phdr = current->phdr; > info.dlpi_phnum = current->phnum; > info.dlpi_adds = gencnt; > -- > 2.35.1.1094.g7c7d902a7c-goog > Any particular reason you chose to create an object for the empty string, instead of just using an empty string? I.e. why not just info.dlpi_name = current==head? "" : current->name; Ciao, Markus ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-04-11 15:52 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-05 3:18 [musl] [PATCH] dl_iterate_phdr: return empty string for the name of the main program Colin Cross 2022-04-05 3:57 ` Michael Forney 2022-04-11 12:24 ` Jeffrey Walton 2022-04-11 12:42 ` Rich Felker 2022-04-11 14:03 ` Jeffrey Walton 2022-04-11 14:58 ` Rich Felker 2022-04-11 15:52 ` Colin Cross 2022-04-11 12:46 ` Florian Weimer 2022-04-05 4:43 ` Markus Wichmann
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).