Re: dlfcn.h dlopen() problem

[Fabrice Bauzac <libnoon at gmail dot com>]

Hello,

2013/7/12 Fabrice Bauzac <libnoon@gmail.com>:
> 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...

What do you think?

Thanks!

Best regards
Fabrice