Date: Sat, 17 Jan 1998 18:48:06 -0800 From: John Polstra <jdp@polstra.com> To: hasty@rah.star-gate.com Cc: hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801180248.SAA09258@austin.polstra.com> In-Reply-To: <199801172227.OAA06497@rah.star-gate.com> References: <199801172227.OAA06497@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199801172227.OAA06497@rah.star-gate.com>, Amancio Hasty <hasty@rah.star-gate.com> wrote: > Not sure that I understand whats going on . when the kernel loads > an image it has the full path If you execute a program by typing something like "./foo" then the kernel only has a relative path. So you also have to know the pathname of the working directory at the time of the exec. > we save the path -- the most intuitive place is the proc > structure. I don't purport to speak for David Greenman, but I would guess that anything like this that slowed down every exec might not make him too happy. An acceptable solution should have virtually zero impact except on processes that actually call dladdr. I think that's probably do-able. One idea (not well thought through, so it might not work) would be to have the kernel save pointers to the vnode of the executable and the vnode of the directory that contained it at exec time. I think that from those two things it should be possible to compute a full pathname later on. Of course, it would fail if somebody (re)moved the executable file after it was already running, but so would just about any approach. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801180248.SAA09258>