Question about setting argv[0] when manually using dynamic linker

Question about setting argv[0] when manually using dynamic linker

[John Regan]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi there - I was wondering if it's possible to somehow set argv[0] when
calling the dynamic linker to load a program.

The reason I want to do this (in case there's a better way) - I was looking
into compiling programs with musl libc, and distributing the binaries with
the needed libc.so file, so I could have a directory structure like:

/bin
|  app
/lib
|  libc.so
|  some_other_lib.so

I can set the rpath to $ORIGIN/../lib so the whole folder is relocatable,
but as far as i know, there's no equivalent concept for setting the dynamic
linker with a path that's relative to the binary.

My current idea is to have a wrapper script, so my structure would be
something like:

/bin
|  app.bin <- actual binary
|  app
/lib
|  libc.so
|  some_other_lib.so

The 'app' script could find the actual, absolute path to itself and figure
out where libc.so is, ending with a line like

exec /path/to/libc.so /path/to/app.bin arg1 arg2 etc

I'd like to retain whatever was actually typed on the command line (in this
case, set argv[0] to "app"), since many apps look at argv[0] to change
behavior, ie - gzip vs gunzip.

I tried seeing if there was some switch I could pass to the linker, etc -
as far as I can tell, there's no easy way to do this.

Thanks in advance!!

-John Regan

[-- Attachment #2: Type: text/html, Size: 3013 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> Hi there - I was wondering if it's possible to somehow set argv[0] when
> calling the dynamic linker to load a program.
 ...
> I'd like to retain whatever was actually typed on the command line (in this
> case, set argv[0] to "app"), since many apps look at argv[0] to change
> behavior, ie - gzip vs gunzip.
> 
> I tried seeing if there was some switch I could pass to the linker, etc -
> as far as I can tell, there's no easy way to do this.

Set argv[0] to whatever you need when you exec*() the dynamic loader,
which is straightforward with a binary wrapper (not with a shell).

A binary wrapper also adds less overhead then going through a shell.

There is imho hardly any incentive to put such functionalty into the
loader. I say this even though we are dependent here on such tricks,
to work around programs which insist on guessing things when not asked to.

Regards,
Rune

Re: Question about setting argv[0] when manually using dynamic linker

[mzpqnxow]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Is there any reason you want to avoid simply statically linking the
program(s) so that it needs no libc or other shared objects at all?

Or did I misunderstand what you're trying to do?

On Wed, May 17, 2017 at 05:05 <u-uy74@aetey.se> wrote:

> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> > Hi there - I was wondering if it's possible to somehow set argv[0] when
> > calling the dynamic linker to load a program.
>  ...
> > I'd like to retain whatever was actually typed on the command line (in
> this
> > case, set argv[0] to "app"), since many apps look at argv[0] to change
> > behavior, ie - gzip vs gunzip.
> >
> > I tried seeing if there was some switch I could pass to the linker, etc -
> > as far as I can tell, there's no easy way to do this.
>
> Set argv[0] to whatever you need when you exec*() the dynamic loader,
> which is straightforward with a binary wrapper (not with a shell).
>
> A binary wrapper also adds less overhead then going through a shell.
>
> There is imho hardly any incentive to put such functionalty into the
> loader. I say this even though we are dependent here on such tricks,
> to work around programs which insist on guessing things when not asked to.
>
> Regards,
> Rune
>
>

[-- Attachment #2: Type: text/html, Size: 1615 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[mzpqnxow]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

BTW, the shell built-in "exec" has -a which can be used to set argv[0]

Again though, I'm not entire sure I understand your use, so ignore this if
it's irrelevant :>

On Wed, May 17, 2017 at 07:00 mzpqnxow <musl@mzpqnxow.com> wrote:

> Is there any reason you want to avoid simply statically linking the
> program(s) so that it needs no libc or other shared objects at all?
>
> Or did I misunderstand what you're trying to do?
>
> On Wed, May 17, 2017 at 05:05 <u-uy74@aetey.se> wrote:
>
>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
>> > calling the dynamic linker to load a program.
>>  ...
>> > I'd like to retain whatever was actually typed on the command line (in
>> this
>> > case, set argv[0] to "app"), since many apps look at argv[0] to change
>> > behavior, ie - gzip vs gunzip.
>> >
>> > I tried seeing if there was some switch I could pass to the linker, etc
>> -
>> > as far as I can tell, there's no easy way to do this.
>>
>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
>> which is straightforward with a binary wrapper (not with a shell).
>>
>> A binary wrapper also adds less overhead then going through a shell.
>>
>> There is imho hardly any incentive to put such functionalty into the
>> loader. I say this even though we are dependent here on such tricks,
>> to work around programs which insist on guessing things when not asked to.
>>
>> Regards,
>> Rune
>>
>>

[-- Attachment #2: Type: text/html, Size: 2138 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[John Regan]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

On Wed, May 17, 2017 at 11:07 AM, mzpqnxow <musl@mzpqnxow.com> wrote:

> BTW, the shell built-in "exec" has -a which can be used to set argv[0]
>
> Again though, I'm not entire sure I understand your use, so ignore this if
> it's irrelevant :>
>
> On Wed, May 17, 2017 at 07:00 mzpqnxow <musl@mzpqnxow.com> wrote:
>
>> Is there any reason you want to avoid simply statically linking the
>> program(s) so that it needs no libc or other shared objects at all?
>>
>> Or did I misunderstand what you're trying to do?
>>
>> On Wed, May 17, 2017 at 05:05 <u-uy74@aetey.se> wrote:
>>
>>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
>>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
>>> > calling the dynamic linker to load a program.
>>>  ...
>>> > I'd like to retain whatever was actually typed on the command line (in
>>> this
>>> > case, set argv[0] to "app"), since many apps look at argv[0] to change
>>> > behavior, ie - gzip vs gunzip.
>>> >
>>> > I tried seeing if there was some switch I could pass to the linker,
>>> etc -
>>> > as far as I can tell, there's no easy way to do this.
>>>
>>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
>>> which is straightforward with a binary wrapper (not with a shell).
>>>
>>> A binary wrapper also adds less overhead then going through a shell.
>>>
>>> There is imho hardly any incentive to put such functionalty into the
>>> loader. I say this even though we are dependent here on such tricks,
>>> to work around programs which insist on guessing things when not asked
>>> to.
>>>
>>> Regards,
>>> Rune
>>>
>>>
Well, if I statically link I'm unable to dynamically load modules (at least
I'm pretty sure that's the case). There's some cases where that might be
useful.

Right now, I'm really just trying to see "is this doable?". It'd be
interesting to be able to distribute a program with its own libc,
libraries, etc, and still have the ability to dynamically load modules.

[-- Attachment #2: Type: text/html, Size: 3036 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[Rich Felker]

On Wed, May 17, 2017 at 11:16:51AM -0500, John Regan wrote:
> On Wed, May 17, 2017 at 11:07 AM, mzpqnxow <musl@mzpqnxow.com> wrote:
> 
> > BTW, the shell built-in "exec" has -a which can be used to set argv[0]
> >
> > Again though, I'm not entire sure I understand your use, so ignore this if
> > it's irrelevant :>
> >
> > On Wed, May 17, 2017 at 07:00 mzpqnxow <musl@mzpqnxow.com> wrote:
> >
> >> Is there any reason you want to avoid simply statically linking the
> >> program(s) so that it needs no libc or other shared objects at all?
> >>
> >> Or did I misunderstand what you're trying to do?
> >>
> >> On Wed, May 17, 2017 at 05:05 <u-uy74@aetey.se> wrote:
> >>
> >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> >>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
> >>> > calling the dynamic linker to load a program.
> >>>  ...
> >>> > I'd like to retain whatever was actually typed on the command line (in
> >>> this
> >>> > case, set argv[0] to "app"), since many apps look at argv[0] to change
> >>> > behavior, ie - gzip vs gunzip.
> >>> >
> >>> > I tried seeing if there was some switch I could pass to the linker,
> >>> etc -
> >>> > as far as I can tell, there's no easy way to do this.
> >>>
> >>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
> >>> which is straightforward with a binary wrapper (not with a shell).
> >>>
> >>> A binary wrapper also adds less overhead then going through a shell.
> >>>
> >>> There is imho hardly any incentive to put such functionalty into the
> >>> loader. I say this even though we are dependent here on such tricks,
> >>> to work around programs which insist on guessing things when not asked
> >>> to.
> >>>
> >>> Regards,
> >>> Rune
> >>>
> >>>
> Well, if I statically link I'm unable to dynamically load modules (at least
> I'm pretty sure that's the case). There's some cases where that might be
> useful.
> 
> Right now, I'm really just trying to see "is this doable?". It'd be
> interesting to be able to distribute a program with its own libc,
> libraries, etc, and still have the ability to dynamically load modules.

You're right about static linking and dlopen, and what you're doing is
a completely reasonable and recommended way for deploying dynamic
linked apps in a self-contained way that doesn't depend on musl libc
on the host. Unfortunately there's no way to set argv[0] like you want
at this time. Perhaps adding an option like --argv0=foo would be
appropriate.

Rich

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> > >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> > >>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
> > >>> > calling the dynamic linker to load a program.

> > >>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
> > >>> which is straightforward with a binary wrapper (not with a shell).
> > >>>
> > >>> A binary wrapper also adds less overhead then going through a shell.

> > >>> Rune

> a completely reasonable and recommended way for deploying dynamic
> linked apps in a self-contained way that doesn't depend on musl libc
> on the host. Unfortunately there's no way to set argv[0] like you want

We do deploy dynamic linked apps without any dependencies on the libraries
on the host. It works just fine with musl-as-it-is, including the
questionably designed applications like busybox and gcc who
analyze argv[0].

> at this time. Perhaps adding an option like --argv0=foo would be
> appropriate.

What would be the justification for adding the supporting code (to every
instance of the dynamic loader)?

It looks like --argv0=foo is meant to overcome a specific limitation in
bourne shell, in a specific context where the task can be solved easily
and generally better without involving the bourne shell in the first hand.

I would like to see an example of a situation where a wrapper in C (or
any language allowing setting of argv[0]) is less appropriate?

If one really has a reason to express the wrapper in sh, a one-liner in
C and an extra exec from the shell (much cheaper than starting the
shell itself was) is sufficient to make it work.

Rune

Re: Question about setting argv[0] when manually using dynamic linker

[John Regan]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Wed, May 17, 2017 at 2:07 PM, <u-uy74@aetey.se> wrote:

> On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> > > >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> > > >>> > Hi there - I was wondering if it's possible to somehow set
> argv[0] when
> > > >>> > calling the dynamic linker to load a program.
>
> > > >>> Set argv[0] to whatever you need when you exec*() the dynamic
> loader,
> > > >>> which is straightforward with a binary wrapper (not with a shell).
> > > >>>
> > > >>> A binary wrapper also adds less overhead then going through a
> shell.
>
> > > >>> Rune
>
> > a completely reasonable and recommended way for deploying dynamic
> > linked apps in a self-contained way that doesn't depend on musl libc
> > on the host. Unfortunately there's no way to set argv[0] like you want
>
> We do deploy dynamic linked apps without any dependencies on the libraries
> on the host. It works just fine with musl-as-it-is, including the
> questionably designed applications like busybox and gcc who
> analyze argv[0].
>
> > at this time. Perhaps adding an option like --argv0=foo would be
> > appropriate.
>
> What would be the justification for adding the supporting code (to every
> instance of the dynamic loader)?
>
> It looks like --argv0=foo is meant to overcome a specific limitation in
> bourne shell, in a specific context where the task can be solved easily
> and generally better without involving the bourne shell in the first hand.
>
> I would like to see an example of a situation where a wrapper in C (or
> any language allowing setting of argv[0]) is less appropriate?
>
> If one really has a reason to express the wrapper in sh, a one-liner in
> C and an extra exec from the shell (much cheaper than starting the
> shell itself was) is sufficient to make it work.
>
> Rune
>
> Hi Rune - would you mind sharing some tips on doing that?

I wrote and compiled a short program that just dumps the elements in argv,
then a wrapper program that figures out the needed paths for libc, real
binary, etc, but it seems like argv[0] gets reset by the dynamic loader.

I'm calling execve with the path to the libc.so, and argv is somenthing
like:

argv[0] - desired process name
argv[1] - full path to the real binary
argv[2...] arguments

The 'real' binary is loaded and ran, but winds up printing out:

argv[0] - full path to the real binary
argv[1...] arguments

[-- Attachment #2: Type: text/html, Size: 3841 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Wed, May 17, 2017 at 02:16:09PM -0500, John Regan wrote:
> On Wed, May 17, 2017 at 2:07 PM, <u-uy74@aetey.se> wrote:
> > We do deploy dynamic linked apps without any dependencies on the libraries
> > on the host. It works just fine with musl-as-it-is, including the
> > questionably designed applications like busybox and gcc who
> > analyze argv[0].

> I wrote and compiled a short program that just dumps the elements in argv,
> then a wrapper program that figures out the needed paths for libc, real
> binary, etc, but it seems like argv[0] gets reset by the dynamic loader.

Oh, here you caught me.

Apologies.

Indeed the program does not see argv[0] because the linker shifts the
arguments.

Please disregard my statement above.

It is "correct" to the point that it works but yes we have
to do unpleasant tricks for the programs analyzing argv[0],
I just happened to have repressed that pain.

(We do also reset argv[0] but for an unrelated purpose, I confused the two
cases and posted without verifying).

Rich is right, there is indeed no good alternative to --argv0=foo.
It would be welcome.

Sorry for the noise!

Rune

Re: Question about setting argv[0] when manually using dynamic linker

[mzpqnxow]

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

Does the shell built-in "exec" -a app1 /bah/dynamic-loader.so
/path/to/app1" work or it has the same problem with argv[0] getting reset?

On Wed, May 17, 2017 at 15:16 John Regan <saxindustries@gmail.com> wrote:

>
> On Wed, May 17, 2017 at 2:07 PM, <u-uy74@aetey.se> wrote:
>
>> On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
>> > > >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
>> > > >>> > Hi there - I was wondering if it's possible to somehow set
>> argv[0] when
>> > > >>> > calling the dynamic linker to load a program.
>>
>> > > >>> Set argv[0] to whatever you need when you exec*() the dynamic
>> loader,
>> > > >>> which is straightforward with a binary wrapper (not with a shell).
>> > > >>>
>> > > >>> A binary wrapper also adds less overhead then going through a
>> shell.
>>
>> > > >>> Rune
>>
>> > a completely reasonable and recommended way for deploying dynamic
>> > linked apps in a self-contained way that doesn't depend on musl libc
>> > on the host. Unfortunately there's no way to set argv[0] like you want
>>
>> We do deploy dynamic linked apps without any dependencies on the libraries
>> on the host. It works just fine with musl-as-it-is, including the
>> questionably designed applications like busybox and gcc who
>> analyze argv[0].
>>
>> > at this time. Perhaps adding an option like --argv0=foo would be
>> > appropriate.
>>
>> What would be the justification for adding the supporting code (to every
>> instance of the dynamic loader)?
>>
>> It looks like --argv0=foo is meant to overcome a specific limitation in
>> bourne shell, in a specific context where the task can be solved easily
>> and generally better without involving the bourne shell in the first hand.
>>
>> I would like to see an example of a situation where a wrapper in C (or
>> any language allowing setting of argv[0]) is less appropriate?
>>
>> If one really has a reason to express the wrapper in sh, a one-liner in
>> C and an extra exec from the shell (much cheaper than starting the
>> shell itself was) is sufficient to make it work.
>>
>> Rune
>>
>> Hi Rune - would you mind sharing some tips on doing that?
>
> I wrote and compiled a short program that just dumps the elements in argv,
> then a wrapper program that figures out the needed paths for libc, real
> binary, etc, but it seems like argv[0] gets reset by the dynamic loader.
>
> I'm calling execve with the path to the libc.so, and argv is somenthing
> like:
>
> argv[0] - desired process name
> argv[1] - full path to the real binary
> argv[2...] arguments
>
> The 'real' binary is loaded and ran, but winds up printing out:
>
> argv[0] - full path to the real binary
> argv[1...] arguments
>

[-- Attachment #2: Type: text/html, Size: 4287 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[John Regan]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Wed, May 17, 2017 at 4:15 PM, mzpqnxow <musl@mzpqnxow.com> wrote:

> Does the shell built-in "exec" -a app1 /bah/dynamic-loader.so
> /path/to/app1" work or it has the same problem with argv[0] getting reset?
>
>
It looks like argv[0] gets reset. Plus I don't think every shell's built-in
"exec" supports that -a flag. I don't see it mentioned in the POSIX man
page for exec -
http://pubs.opengroup.org/onlinepubs/009604599/utilities/exec.html - nor do
I see anything about it on the dash man page -
https://linux.die.net/man/1/dash, I suspect that's specific to bash.

[-- Attachment #2: Type: text/html, Size: 1490 bytes --]

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> a completely reasonable and recommended way for deploying dynamic
> linked apps in a self-contained way that doesn't depend on musl libc
> on the host. Unfortunately there's no way to set argv[0] like you want
> at this time. Perhaps adding an option like --argv0=foo would be
> appropriate.

Is this option being considered to introduce?

It is apparently crucial for certain cases, and definitely useful
even when it is within reach to influence/patch the programs relying
on argv[0].

Regards,
Rune

Re: Question about setting argv[0] when manually using dynamic linker

[Rich Felker]

On Sun, Jul 02, 2017 at 07:36:19PM +0200, u-uy74@aetey.se wrote:
> On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> > a completely reasonable and recommended way for deploying dynamic
> > linked apps in a self-contained way that doesn't depend on musl libc
> > on the host. Unfortunately there's no way to set argv[0] like you want
> > at this time. Perhaps adding an option like --argv0=foo would be
> > appropriate.
> 
> Is this option being considered to introduce?
> 
> It is apparently crucial for certain cases, and definitely useful
> even when it is within reach to influence/patch the programs relying
> on argv[0].

Yes, adding it.

Rich

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Tue, Jul 04, 2017 at 04:58:11PM -0400, Rich Felker wrote:
> > It is apparently crucial for certain cases, and definitely useful
> > even when it is within reach to influence/patch the programs relying
> > on argv[0].
> 
> Yes, adding it.

Thanks!

Rune

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Tue, Jul 04, 2017 at 04:58:11PM -0400, Rich Felker wrote:
> On Sun, Jul 02, 2017 at 07:36:19PM +0200, u-uy74@aetey.se wrote:
> > On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> > > Perhaps adding an option like --argv0=foo would be
> > > appropriate.
> > 
> > Is this option being considered to introduce?

> Yes, adding it.

Thanks again, it makes some "unsolvable" cases work as needed.

OTOH when applying this in practice, I noticed that a slightly
different behaviour would be very handy: if the linker could
supply its own argv[0] as the one for the program to run.

This would fit nicely into the framework where we already set argv[0]
anyway, in the same way for both statically and dynamically linked
programs. (The only exception so far would be a hypothetical need to
pass on the value "ldd" as argv[0], then --argv0=ldd would save the day)

Otherwise we have to set the dynloader --argv0 argument per binary
which is of course possible but remarkably less convenient,
among others because this setting is dynloader-specific, while
otherwise our tools are libc- and dynamic vs static agnostic.

IOW as long as the loader itself does not rely on its argv[0]
too much, plainly passing on argv[0] is a very practical means to
handle the programs like busybox and gcc transparently.

What about always passing on the loader argv[0] unless --argv0 is present?
This will not matter for programs which do not analyze argv[0]
and will not make it worse for programs which do.

--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -1388,7 +1388,7 @@
                kernel_mapped_dso(&app);
        } else {
                int fd;
-               char *ldname = argv[0];
+               char *ldname = replace_argv0 = argv[0];
                size_t l = strlen(ldname);
                if (l >= 3 && !strcmp(ldname+l-3, "ldd")) ldd_mode = 1;
                argv++;

or even

--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -1322,7 +1322,7 @@
        size_t aux[AUX_CNT], *auxv;
        size_t i;
        char *env_preload=0;
-       char *replace_argv0=0;
+       char *replace_argv0=argv[0];
        size_t vdso_base;
        int argc = *sp;
        char **argv = (void *)(sp+1);
@@ -1567,7 +1567,7 @@
        debug.state = 0;
        _dl_debug_state();

-       if (replace_argv0) argv[0] = replace_argv0;
+       argv[0] = replace_argv0;

        errno = 0;
 

Otherwise may be something like this:

--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -1409,6 +1409,7 @@
                                else if (*argv) env_preload = *argv++;
                        } else if (!memcmp(opt, "argv0", 5)) {
                                if (opt[5]=='=') replace_argv0 = opt+6;
+                               else if (opt[5]=='^') replace_argv0 = ldname;
                                else if (opt[5]) *argv = 0;
                                else if (*argv) replace_argv0 = *argv++;
                        } else {

to instead introduce an extra --argv0^ option ?

Regards,
Rune

Re: Question about setting argv[0] when manually using dynamic linker

[Rich Felker]

On Sun, Jul 09, 2017 at 11:23:23AM +0200, u-uy74@aetey.se wrote:
> On Tue, Jul 04, 2017 at 04:58:11PM -0400, Rich Felker wrote:
> > On Sun, Jul 02, 2017 at 07:36:19PM +0200, u-uy74@aetey.se wrote:
> > > On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote:
> > > > Perhaps adding an option like --argv0=foo would be
> > > > appropriate.
> > > 
> > > Is this option being considered to introduce?
> 
> > Yes, adding it.
> 
> Thanks again, it makes some "unsolvable" cases work as needed.
> 
> OTOH when applying this in practice, I noticed that a slightly
> different behaviour would be very handy: if the linker could
> supply its own argv[0] as the one for the program to run.
> 
> This would fit nicely into the framework where we already set argv[0]
> anyway, in the same way for both statically and dynamically linked
> programs. (The only exception so far would be a hypothetical need to
> pass on the value "ldd" as argv[0], then --argv0=ldd would save the day)
> 
> Otherwise we have to set the dynloader --argv0 argument per binary
> which is of course possible but remarkably less convenient,
> among others because this setting is dynloader-specific, while
> otherwise our tools are libc- and dynamic vs static agnostic.
> 
> IOW as long as the loader itself does not rely on its argv[0]
> too much, plainly passing on argv[0] is a very practical means to
> handle the programs like busybox and gcc transparently.
> 
> What about always passing on the loader argv[0] unless --argv0 is present?
> This will not matter for programs which do not analyze argv[0]
> and will not make it worse for programs which do.

This would be a regression in existing behavior and basically breaks
any scripts where the program run wants argv[0] to be its own name.
Otherwise I agree it would be a nicer interface. But I don't see any
reason your invoking program can't just pass the same string it passes
as argv[0] at exec time also as the argument to --argv0.

Rich

Re: Question about setting argv[0] when manually using dynamic linker

[u-uy74]

On Sun, Jul 09, 2017 at 08:23:25AM -0400, Rich Felker wrote:
> On Sun, Jul 09, 2017 at 11:23:23AM +0200, u-uy74@aetey.se wrote:
> > What about always passing on the loader argv[0] unless --argv0 is present?
> > This will not matter for programs which do not analyze argv[0]
> > and will not make it worse for programs which do.
> 
> This would be a regression in existing behavior and basically breaks
> any scripts where the program run wants argv[0] to be its own name.

Indeed, this _can_ make it worse for programs run from existing scripts.
This makes my suggestion moot.

> Otherwise I agree it would be a nicer interface. But I don't see any
> reason your invoking program can't just pass the same string it passes
> as argv[0] at exec time also as the argument to --argv0.

Certainly it can, this just happens to be practically inconvenient.

Such a change needs some new config syntax, some coding, testing,
documentation and then modification and testing of a noticeable number of
configuration instances. Sigh. Given that the "existing scripts depending
on the old behaviour" are irrelevant here, it does not feel right. :)

Of course this is not an argument for upstream.

Never mind, we can either bite the bullet and use --argv0 as it is meant
to, or make the "pass-on" change to our copy of the dynloader.

Thanks (for musl and for --argv0) !
Rune