Re: dlfcn.h dlopen() problem

[Mike Frysinger <vapier at gentoo dot org>]

On Thursday 01 August 2013 11:25:17 Fabrice Bauzac wrote:
> 2013/7/12 Fabrice Bauzac:
> > In dlfcn.h I have this definition of dlopen():
> > /* Open the shared object FILE and map it in; return a handle that can be
> > 
> >    passed to `dlsym' to get symbol values from it.  */
> > 
> > extern void *dlopen (const char *__file, int __mode) __THROW;
> > 
> > According to cc -O2 -save-temps file.c (look at the generated .i),
> > __THROW means:
> > __attribute__((nothrow, leaf))
> > 
> > Maybe it is the "leaf" attribute that allows gcc to remove the
> > "var=3;" assignment?  See
> > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
> > 
> > Maybe dlopen() should not be marked as "leaf".  What do you think?
> 
> I think the problem lies in this "leaf" attribute to dlopen().
> The dlopen() documentation (manpage) explicitly says that
> __attribute__((constructor)) functions (or _init()) are called while
> dlopen() executes.
> The GCC documentation says that whenever a "leaf" external function is
> called from a compilation unit, it cannot access that compilation unit
> (neither variables nor functions). That's basically a contract by the
> code to the compiler.
> 
> The fact that my dlopened() library accesses the caller's exported
> symbols might not look pretty, but I see no reason why this kind of
> access would have to be forbidden in general.  I suggest removing the
> "leaf" attribute to dlopen().
> Otherwise, I could remove optimization or add some "volatile"
> qualifiers, but that looks like a hack to me...

i've posted a patch to libc-alpha to change the __THROW to __THROWNL for the 
dlopen/dlclose funcs.  thanks for the in-depth analysis !
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.