Date: Tue, 12 Feb 2002 23:49:51 +0100 From: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: problem w/ dlopen(); bug or feature? Message-ID: <20020212224951.GA1230@frolic.no-support.loc> In-Reply-To: <200202020424.g124OXD03238@vashon.polstra.com> References: <20020201201018.GB2992@frolic.no-support.loc> <20020201212028.GC2992@frolic.no-support.loc> <200202020424.g124OXD03238@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello John,
> > John, is it possible to find out in dlopen() which object in the
> > linked list has issued the dlopen() call? Then a fix would be easy.
>=20
> Yes, it's possible to find out which shared object the dlopen call
> was made from. There's already a function obj_from_addr() in rtld.c
> which does that.
Based on your hint, I made a small patch, that enables the runtime
linker to search the RPATH of the object which issued the dlopen() call
on dlopen(). This new behaviour can be activated by setting the
environment variable LD_SUN_DLOPEN.
Additionally I've inspected some other operating systems wrt the
searching method for dlopen():
IRIX 6.2: Searches the RPATH of the object that issued the dlopen()
call and the RPATH of the main object. Earlier version
(pre 6.0?) only searched the RPATH of the main object.
OSF 4.0F: Searches only the RPATH of the main object. I'm still
trying to get my fingers on a 5.0 machine. Newer OSF
versions may already search the RPATH of the object
that issued the dlopen(). Although this is not ELF,
DEC/Compaq tries to make with ECOFF what others do
with ELF.
SunOS 5.5.1: Searches only the RPATH of the object that issued the
dlopen() call. Personally I think, this is the most
rational behavior.
This patch is primarily for testing and evaluating the dlopen() search
path behaviour of the SunOS linker in the FreeBSD environment.
The LD_SUN_DLOPEN variable should be dumped after the test phase; the
LD_* name space is already congested.
I've tested this thoroughly on a 4.5-RELEASE, but I don't use the
ports system (don't ask), so someone with a lot of installed ports
may run some tests.
-Bj=F6rn
--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rtld-elf.udif"
--- rtld.c 2002/02/01 20:17:01 1.1
+++ rtld.c 2002/02/12 19:50:13
@@ -1553,6 +1553,18 @@
obj->refcount++;
} else {
char *path = find_library(name, obj_main);
+ if (getenv("LD_SUN_DLOPEN")) {
+ /*
+ * Mimic the behaviour of the SunOS runtime linker: Use the
+ * rpath of the object that issued the dlopen() call for the
+ * lookup of the dso that should be dlopened.
+ *
+ * __builtin_return_address() is __GNUC__ only
+ */
+ Obj_Entry *refobj = obj_from_addr(__builtin_return_address(0));
+ if (refobj != NULL)
+ path = find_library(name, refobj);
+ }
if (path != NULL)
obj = load_object(path);
}
--SUOF0GtieIMvvwua--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020212224951.GA1230>