From owner-freebsd-hackers  Sun Jan 18 05:50:26 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id FAA04898
          for hackers-outgoing; Sun, 18 Jan 1998 05:50:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from rah.star-gate.com ([209.133.7.178])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA04803
          for <hackers@freebsd.org>; Sun, 18 Jan 1998 05:49:42 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id WAA00766;
          Sat, 17 Jan 1998 22:04:24 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199801180604.WAA00766@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: John Polstra <jdp@polstra.com>
cc: hackers@FreeBSD.ORG
Subject: Re: dladdr hax 
In-reply-to: Your message of "Sat, 17 Jan 1998 18:48:06 PST."
             <199801180248.SAA09258@austin.polstra.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 17 Jan 1998 22:04:24 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

> 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