From owner-freebsd-hackers  Thu Jan  8 15:15:31 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA15134
          for hackers-outgoing; Thu, 8 Jan 1998 15:15:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from damon.com (root@damon.com [207.170.114.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15109
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 8 Jan 1998 15:15:07 -0800 (PST)
          (envelope-from dap@damon.com)
Received: (from dap@localhost) by damon.com (8.8.3/8.8.3) id RAA20001; Thu, 8 Jan 1998 17:12:38 -0600 (CST)
From: Damon Anton Permezel <dap@damon.com>
Message-Id: <199801082312.RAA20001@damon.com>
Subject: dladdr hax
To: hasty@rah.star-gate.com (Amancio Hasty)
Date: Thu, 8 Jan 1998 17:12:38 -0600 (CST)
Cc: tlambert@primenet.com, dap@damon.com, nate@mt.sri.com,
        freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199801081837.KAA02418@rah.star-gate.com> from Amancio Hasty at "Jan 8, 98 10:37:09 am"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

"Amancio Hasty sez: "
> 
> Hi,
> 
> I know what dladdr is its just that we don't have an implementation for it.
> 
> So who is the right person to ask to make sure that dladdr gets implemented?
> 
> 	Cheers,
> 	Amancio
> 

I'd do it, but I have no access, *and* I have concerns about having to
hack on the kernel to support java.  I'd prefer if the JDK worked on
"all recent versions", but certain enhancements can be accomodated dynamically.

My understanding of it is that it requires the full path be kept by execve().
It can either be stored in the u area, or can be copied into the new address
space somewhere, ala argv/envp.  This makes it easier for ld.so to know where
it is, and then the dladdr hack follows quite easily.
If it is kept in the u area, then some mechanism needs to be dreamed up to
let ld.so get at it, which I like less.

There are probably precedents which should be looked at and possible followed,
but that is the hard part.

Anyway, I have kluged it by having all the shell script wrappers put it in the
environment.  The kluge is not guaranteed to work, but my understanding
(which I admit might be wrong) was that this was so that "apps" could be
written which come with their own big-mess-of-java-gorp, and if one follows
some conventions when putting it all together, then the default library
path gets set appropriately.  Since I have not seen anything which relied on
this, and haven't attempted to construct such a beast, perhaps i'm just off
in the weeds...

Here's the kluge i use: (the first 3 lines are standard java wrapper setup)

PRG=`whence $0` >/dev/null 2>&1
J_HOME=`dirname $PRG`/..
progname=`basename $0`

export __cmd_path_kluge=$PRG


Then I use the __cmd_path_kluge, if set:;

    if (default_classpath == NULL) {
	char *ep;

	/*
	 * there doesn't appear to be a way to get the exec path, so
	 * we add this kluge to the java wrappers.
	 */
	if ((ep = getenv("__cmd_path_kluge")) != 0) {
	    jio_snprintf(buf, PATH_MAX, "%s", ep);

	    *(strrchr(buf, '/')) = '\0';
	    default_classpath = malloc(strlen(buf) * 5 + 100);
	    sprintf(default_classpath, 
		    "%s/../../../classes:"
		    "%s/../../classes.zip:"
		    "%s/../../classes.jar:"
		    "%s/../../rt.jar:"
		    "%s/../../i18n.jar",
		    buf, buf, buf, buf, buf);