Date: Mon, 12 Jan 1998 19:16:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dap@damon.com (Damon Anton Permezel) Cc: tlambert@primenet.com, dap@damon.com, hasty@rah.star-gate.com, nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801121916.MAA27296@usr04.primenet.com> In-Reply-To: <199801092342.RAA25140@damon.com> from "Damon Anton Permezel" at Jan 9, 98 05:42:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > --------------------------------------------------------------------------
> > 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?
Behaviour is undefined (argv[ 0] is filled out by the shell, which
makes it dependent upon the shell implementation as to what value
gets thrown in there.
I used (launch.c):
#include <unistd.h>
main()
{
execl( "./dladdr", "frobozzco", NULL);
}
And, of course, got:
file containing address range "frobozzco"
8-).
> 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.
They're loons. 8-).
You can't dictate shell behaviour like this. I could, as easily,
given the real name, but lied about the value of "PATH", calling
execle() to substitute an environment. This would have made any
attempt to look up the real path, from a relative path, fail.
The reason I'm kind of harping on this point is that I want an
execution calss that starts a "script interpreter" in a JRE. I
*want* to substitute the environment, and load a JIT'ing JRE
with the actuall class name as an argument, when the class file is
referenced directly, by name, in an execve.
In other words, I want java support "in the kernel".
> 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.
It gives me (the executable is not in the current directory):
file containing address range "dladdr"
Sorry. This is probably why Sun has the shell script glue with
the full path specified. They are making presumptions about their
shells.
> if not, then the code to implement this doesn't make sense, is broken, and
> we don't have to worry about it.
Technically, it can be argued that crt0.o should not be doing the
ld.so mmap... that instead, the mapping should be done by the execution
class loader; at the same time, the execution class loader should
pre-stuff the expanded path to the file exec'ed into the data space
of the newly mapped ld.so.
There is actually space reserved at the front of the process address
map for a zero page, folloed by an ld.so mapped by the program loader
instead of teh crt0.o.
The loader would also have to stuff the .entry for the loaded
executable into the ld.so data space as well, and then jump to the
ld.so's .entry and assume the ld.so will call the entry by reference
from it's data space when it is done with constructing virtual base
classes for C++ libraries, or whatever the heck it thinks it needs to
do. Probably it will always map libc.so, if only for the system calls
(makes you want a seperate ELF segment for system calls vs. other libc
routines... 8-)).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801121916.MAA27296>