Date: Thu, 8 Jan 1998 19:49:43 -0600 (CST) From: Damon Anton Permezel <dap@damon.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: dap@damon.com, hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.ORG, nate@mt.sri.com, tlambert@primenet.com Subject: Re: dladdr hax Message-ID: <199801090149.TAA20694@damon.com> In-Reply-To: <199801082328.PAA04229@rah.star-gate.com> from Amancio Hasty at "Jan 8, 98 03:28:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
"Amancio Hasty sez: " > Well, the exec part is component the other is that dladdr is used > to locate where a library was loaded from. Again, for the command path > argv[0] clearly tells you where the command got executed from. Nope. argv[0] doesn't. > > If I am not mistaken the command execution portion should be also > in the U area or some clever location for the ps to be able to > display it. I thought it used to be u.u_comm. There is a p_comm now. This doesn't contain the full path. It has space for 16 characters of the last component of the name. ps only uses p_comm if argv[0] has been cleared, or omitted, otherwise, it uses argv[0], which is usually not absolute. One generally doesn't want space for PATHNAMEMAX chars lingering about in the proc[], or the uarea. >From a cursory look at ld.so: ld.so already keeps the path of the shared libraries in an internal table. All we need is the interface defined (dladdr(), you say?) to search the table for the range, and return the som_path. All I need now is some time... =dap
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801090149.TAA20694>