[PATCH v5 16/22] elf: Add main application on main_map l_name

[Adhemerval Zanella]

On 11/11/2021 09:39, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> For the la_objopen() the path listed in link_map->l_name for the main
>> application binary is empty, even though dladdr() is able to recover the
>> correct path.
>>
>> By setting the expected application name on l_name, it allows to
>> simplify the code to handle the special case and make the API that
>> return such information (la_objopen(), dladdr() and dlinfo() to have
>> similar semantic.
> 
> _dl_argv[0] is not a path name.
> 
> After “bash -c 'exec -a not-a-real-path cat'”, we have this:
> 
> (gdb) print _dl_argv[0]
> $1 = 0x7ffc1feaf3de "not-a-real-path"

This is what program_invocation_name/__progname  (initialized at __init_misc())
assumes.  I think it is a fair assumption, since by convention the first string 
in argv on execve() is the filename associated with the file being executed.

Also, if users really want something different to use as the program name
they can use argv[0] which will be aligned in the various APIs.

> 
> I think dladdr is wrong to use this as a path.

I don't think so, glibc itself uses it in multiples places to get the 
program name and also exports program_invocation_name/program_invocation_short_name
as GNU extensions.  Another option would to read /proc/self/cmdline, but I don'
think this would be really an improvement (and it is not easily override by
the users).

> 
> I think in practice l_name == "" means that the link map is for the main
> executable.  This seems particularly relevant given that the public part
> of the link map does not expose lt_executable.

This is one reason I consider to not expose this in the link_map, however I
still think to align la_objopen(), dladdr() and dlinfo() seems to be a better
QoI than asking users to check program_invocation_name.