Date: Fri, 9 Jan 1998 17:42:29 -0600 (CST) From: Damon Anton Permezel <dap@damon.com> To: tlambert@primenet.com (Terry Lambert) Cc: dap@damon.com, hasty@rah.star-gate.com, tlambert@primenet.com, nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801092342.RAA25140@damon.com> In-Reply-To: <199801092252.PAA00624@usr04.primenet.com> from Terry Lambert at "Jan 9, 98 10:52:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
"Terry Lambert sez: "
> >
> > My understanding of it is that it requires the full path be kept by execve().
> Actually, this isn't true. It's pretty trivial to write and run a
> dladdr using program on a solaris box.
Actually it is true, and it looks like Solaris JDK has the same bug we do
(with the kluge I employed).
>
> If you do this in the main program:
> --------------------------------------------------------------------------
> file containing address range "./dladdr"
This is the bug. If you don't use "./dladdr", but put it somewhere in you
$PATH, then what happens?
>
> HOWEVER...
>
> If I use the function as JAVA uses the function, and call it on a
> a local address from *within* a shared library, the expression "&printf"
> will refer to the address of the printf function in the library.
The point I am attempting to make is that this is not the only use made of
it. Look at jre_md.c. You will see that in that instance, they are
attempting to get the path to the executable, via explicitly using a
non-shared address, which, as you point out, returns the equivalent of
argv[0].
They are expecting this to be the full, absolute path.
Here is an extraction:
/*
* Returns default Java home based on location of this executable.
*/
char *
GetDefaultJavaHome() { ... }
They dladdr &GetDefaultJavaHome.
xylyl% nm jre
00001020 F /usr/lib/crt0.o
000020e4 T _AddProperty
00002178 T _DeleteProperty
00002a24 T _GetDefaultJavaHome
Since you have access to solaris, and have that programme at hand,
please run it from a $PATH location, and let me know if it gives you
the full path or not.
if not, then the code to implement this doesn't make sense, is broken, and
we don't have to worry about it.
If so, then I still believe that FreeBSD execve() will have to be modified
in order to pass the full path to the executable so ld.so can find it and
populate the initial som_path.
In any event, there are more pressing bugs to deal with in the JDK port.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801092342.RAA25140>