Date: Sat, 17 Jan 1998 22:04:24 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: John Polstra <jdp@polstra.com> Cc: hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801180604.WAA00766@rah.star-gate.com> In-Reply-To: Your message of "Sat, 17 Jan 1998 18:48:06 PST." <199801180248.SAA09258@austin.polstra.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. > Thats an interesting approach so what happens to a vnode of a running executable when is mark for delete? I kind doubt that the vnode goes away while the image is still executing 8) Regards, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801180604.WAA00766>