This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/15897] New: dlopen/dlclose should not be marked as leaf functions
- From: "vapier at gentoo dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 27 Aug 2013 04:46:50 +0000
- Subject: [Bug dynamic-link/15897] New: dlopen/dlclose should not be marked as leaf functions
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=15897
Bug ID: 15897
Summary: dlopen/dlclose should not be marked as leaf functions
Product: glibc
Version: unspecified
URL: https://sourceware.org/ml/libc-help/2013-07/msg00015.h
tml
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: vapier at gentoo dot org
as reported by Fabrice Bauzac:
I might have found a bug in glibc.
On my Ubuntu64 server I have glibc 2.17 (see attached libc.version)
and gcc 4.7.3.
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;
I have a small test case with a static variable and a call to dlopen()
or a similar function: see attached main.c.
When I compile with the given Makefile
cc -O2 -Wall -Wextra -save-temps -S -o main.s main.c
the generated assembly code (attached main.s) does not contain the
assignment "var=3;" anymore. I think it is a bug: the assignment
"var=3" should be done, because in the .so if there are constructors
(functions called at dlopen() time) they might use "var" indirectly
via the function increase_var(). And that's what is currently
happening to me (in a more complex case): I have a constructor that
actually needs some "var" to be set to 3.
Now why is this assignment removed by the compiler?
If in call_external_function() I call my_external_function() instead
of dlopen(), the problem remains, except if I remove the __THROW
attribute in which case "var" is assigned 3, then the funcall is done,
then "var" is assigned to 0.
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?
--
You are receiving this mail because:
You are on the CC list for the bug.