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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/58865; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: lib/58865: static and dynamic dl_iterate_phdr disagree on main
	object name
Date: Sat, 30 Nov 2024 19:59:17 +0000

 > 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.)