Re: lib/58865: static and dynamic dl_iterate_phdr disagree on main object name

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 30 Nov 2024 13:32:17 -0500
> From: Christos Zoulas <christos%zoulas.com@localhost>
>  
> FreeBSD does not process AT_SUN_EXECNAME at all.

FreeBSD does have AT_EXECPATH, with slightly different semantics:

- Our AT_SUN_EXECNAME is essentially:

	$(pwd)/${path}

  which will include ./ or symlink components in ${path}, e.g. `cd
  /tmp && ./foo' will pass `/tmp/./foo' and `cd /tmp && ln -s .
  symlink && ./symlink/foo' will pass `/tmp/./symlink/foo'.

- FreeBSD's AT_EXECPATH is ${path} if absolute, or essentially:

	$(cd "$(dirname "${path}")" && pwd)/$(basename "${path}")

  (or if that fails, ${path} even if relative), which will usually
  avoid any ./ components and symlink components in ${path} when the
  argument to execve(2) is relative.

No opinion here about which approach is right and which approach is
wrong -- just observing what is implemented.

It might be nice if the exact path passed to execve(2) were provided
in some way -- not necessarily via AT_SUN_EXECNAME -- for the program,
which can always prepend $(pwd) or filter through dirname/pwd/basename
if it wants.  As far as I can tell there's no way to get this right
now since $(pwd) might change between when the kernel adds it and when
userland might try to strip it from AT_SUN_EXECNAME, and there's no
guarantee argv[0] has any connection to the execve(2) path.  But it is
always a suffix of AT_SUN_EXECNAME at the moment.

> But I think you are right, might as well use the full path for the
> name.  The Dl_info will be different as returned from dladdr(3), the
> linkmap entry as returned by dlinfo(3), and the error messages from
> the linker itself.  It will look non-familiar to the user (why I
> typed ./foo and the error message is /path/foo?), but I think it is
> better (since it provides an absolute path) and should not break
> anything.

FreeBSD appears to use AT_EXECPATH for these, not argv[0] unless
AT_EXECPATH is missing -- so it will get the fully resolved path,
closer to what AT_SUN_EXECNAME gives than argv[0].  (But OpenBSD uses
argv[0] -- doesn't seem to have anything like AT_EXECPATH or
AT_SUN_EXECNAME.)