This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: _dlfcn_hook and SHARED
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Mathieu Lacage" <mathieu dot lacage at sophia dot inria dot fr>
- Cc: libc-help at sourceware dot org
- Date: Thu, 7 Aug 2008 22:42:29 -0400
- Subject: Re: _dlfcn_hook and SHARED
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=q543mqAHuaostryG7nMHbreQjyjcgENdl3Cs6RbOjRE=; b=VUY8YBWz0sKY0sEYBwBGjsNpY3VNxzc/lAp6xkjrebKQAQS9tiRNHoyFcplW+YnlLz GARa716UqyVSabdAuqUGu4DlP/EfVbYIhOUDsSt24HzbiJSctqe1Q3Ye7U/eKZCdogkm /W+TBIBitYKUXZcVLkdu0hwo3Dr4H2F2inF0A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=U16gv9bo2D3kKTtkq5n522/m58t2IUFZ3C4IqV8YHCHQNJPtA0q2B2drbEXQUrNCC4 /DEUjMyymDzJfveV0b7Rm7QdfiMV1sjcCNRTd5bxi+IwdzfR94iKpoDiwBO2GRokJM4y JM42vvpHQPPfob2DKmUV9wbEMk/oqWiXO/Ebo=
- References: <1216677518.15697.44.camel@ns-test>
On Mon, Jul 21, 2008 at 5:58 PM, Mathieu Lacage
<mathieu.lacage@sophia.inria.fr> wrote:
> while trying to go through the glibc dlfcn/elf source code, I stumbled
> upon the _dlfcn_hook global variable defined in dlfcn/dlerror.c: this
> pointer is initialized to zero (nocommon attribute) and is tested
> extensively at the start of each of the __dlfoo functions for equality
> to NULL when the macro SHARED is defined.
>
> I have, however, been unable to find anywhere this pointer would be
> reset to anything but NULL when SHARED is defined. This begs the
> question: where is _dlfcn_hook ever set to anything but NULL when SHARED
> is defined ?
A statically compiled application will have a copy of all the dl* functions.
If that statically compiled application tries to dlopen a shared
object, there are *may* be two copies of all the dl* functions (and
two copies of the data).
The only way to make this work is to force the newly loaded second
copy of the functions to call back into the static versions.
This song-and-dance allows glibc to support dlopen'd NSS modules from
statically linked applications.
Someone else can correct me if I'm wrong :-)
Cheers,
Carlos.