Date: Sat, 2 Feb 2002 13:51:08 +0100 From: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> To: John Polstra <jdp@polstra.com> 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> 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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020202125107.GA481>