From owner-freebsd-hackers Sat Feb 2 4:52:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id 2A9AE37B416 for ; Sat, 2 Feb 2002 04:52:43 -0800 (PST) Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16Wzep-0001XW-09; Sat, 02 Feb 2002 13:52:39 +0100 Received: from frolic.no-support.loc (520094253176-0001@[80.130.220.213]) by fmrl06.sul.t-online.com with esmtp id 16Wzeo-03fxXkC; Sat, 2 Feb 2002 13:52:38 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.6/8.9.3) id g12Cp8E01013; Sat, 2 Feb 2002 13:51:08 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Sat, 2 Feb 2002 13:51:08 +0100 To: John Polstra Cc: hackers@freebsd.org, bfischer@Techfak.Uni-Bielefeld.DE Subject: Re: problem w/ dlopen(); bug or feature? Message-ID: <20020202125107.GA481@frolic.no-support.loc> References: <20020201201018.GB2992@frolic.no-support.loc> <20020201212028.GC2992@frolic.no-support.loc> <200202020424.g124OXD03238@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200202020424.g124OXD03238@vashon.polstra.com> User-Agent: Mutt/1.3.25i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello John, > 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. But as far as I know, it is not standard behavior to > search the RPATH of the object which issued the dlopen call. I only have seen an early draft of the current ELF spec, but I think the search strategy is simply unspecified in this point. Even so, the ELF spec probably would have specified to use the RPATH of the 'parent' object, because the ELF spec targets self containedness for all shared objects. A shared object should be self contained. This is not possible for dlopen()ed objects with the current search strategy of the FreeBSD rtld. > I try > to follow the ELF specification and/or the behavior of Sun's dynamic > linker, and I don't think either one specifies this sort of dynamic > scoping. I've not looked into the source code of Sun's dynamic linker (yet), but=20 I have developed a lot on that platform and I am sure that the linker uses the RPATH of the 'parent' object. You can prove it yourself by running the small dlopen-test code I sent to hackers@ in the first mail of this thread. I tried it on Sparc-Solaris 2.5.1 and x86-Solaris 8. So I would by happy if you adapt the behavior of Sun's dynamic linker for FreeBSD's rtld in this case. > It's risky to get too creative in this area. Usually doing > so breaks several random ports. It is not bad to be conservative, I agree. But isn't it that, what's -CURRENT is for? Ports can be fixed. [tree structure] > If you're talking about functionality, the linked list isn't the > only data structure. Each shared object is also inserted into a > doubly-linked tree structure (actually a DAG) which represents the > hierarchical relationships between the shared objects. That's done > using the "dldags" and "dlmembers" members of the Obj_Entry structure. Exactly. That's what I was looking for. Thanks. -Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message