|
From: Bart V. A. <bar...@gm...> - 2008-04-06 07:22:51
|
The comments in coregrind/m_replacemalloc/vg_replace_malloc.c suggest that the init() function in that file is called just after the shared library this file is linked with has been loaded. This is not correct: __attribute__((constructor)) only makes sense in object files that are linked into an executable, not in object files that are linked into a shared library. See also the gcc manual about this attribute (http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes). Please review. Index: coregrind/m_replacemalloc/vg_replace_malloc.c =================================================================== --- coregrind/m_replacemalloc/vg_replace_malloc.c (revision 7844) +++ coregrind/m_replacemalloc/vg_replace_malloc.c (working copy) @@ -134,8 +138,8 @@ static struct vg_mallocfunc_info info; static int init_done; -/* Startup hook - called as init section */ -static void init(void) __attribute__((constructor)); +/* Initialization function */ +static void init(void); #define MALLOC_TRACE(format, args...) \ if (info.clo_trace_malloc) \ @@ -653,7 +665,7 @@ MALLINFO(m_libc_soname, mallinfo); -/* All the code in here is unused until this function is called */ +/* Call this function before dereferencing any members of 'info'. */ static void init(void) { |
|
From: Tom H. <to...@co...> - 2008-04-06 07:32:55
|
In message <e2e...@ma...>
"Bart Van Assche" <bar...@gm...> wrote:
> The comments in coregrind/m_replacemalloc/vg_replace_malloc.c suggest
> that the init() function in that file is called just after the shared
> library this file is linked with has been loaded. This is not correct:
> __attribute__((constructor)) only makes sense in object files that are
> linked into an executable, not in object files that are linked into a
> shared library. See also the gcc manual about this attribute
> (http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes).
That description is incorrect, or at least misleading.
It never actually says that constructors don't work in shared
objects (they do) it just implies that by saying that they are
run before main is entered.
That is only true for constructors in the main executable and
any shared objects it is linked against however - constructors
in a shared object that it dlopened will be run when the object
is first opened.
In short that attribute is doing something, and shouldn't be
removed.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bart V. A. <bar...@gm...> - 2008-04-09 17:42:59
|
On Sun, Apr 6, 2008 at 9:32 AM, Tom Hughes <to...@co...> wrote: > In message <e2e...@ma...> > > The comments in coregrind/m_replacemalloc/vg_replace_malloc.c suggest > > that the init() function in that file is called just after the shared > > library this file is linked with has been loaded. This is not correct: > > __attribute__((constructor)) only makes sense in object files that are > > linked into an executable, not in object files that are linked into a > > shared library. See also the gcc manual about this attribute > > (http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes). > > That description is incorrect, or at least misleading. > > It never actually says that constructors don't work in shared > objects (they do) it just implies that by saying that they are > run before main is entered. Hello Tom, What is your opinion about the patch below ? The option -nostdlib is replaced by -nodefaultlibs. The effect of this change is that constructors now work in shared objects. The only disadvantage I know of is that this will break compilation with gcc 2.95 -- -nodefaultlibs is only supported in gcc 3.0 and later. Bart. Index: Makefile.flags.am =================================================================== --- Makefile.flags.am (revision 7862) +++ Makefile.flags.am (working copy) @@ -64,8 +64,8 @@ # Baseline link flags for making dynamic shared objects. # -PRELOAD_LDFLAGS_COMMON_LINUX = -nostdlib -shared -Wl,-z,interpose,-z,initfirst -PRELOAD_LDFLAGS_COMMON_AIX5 = -nostdlib -shared -Wl,-G -Wl,-bnogc +PRELOAD_LDFLAGS_COMMON_LINUX = -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst +PRELOAD_LDFLAGS_COMMON_AIX5 = -nodefaultlibs -shared -Wl,-G -Wl,-bnogc PRELOAD_LDFLAGS_X86_LINUX = $(PRELOAD_LDFLAGS_COMMON_LINUX) @FLAG_M32@ PRELOAD_LDFLAGS_AMD64_LINUX = $(PRELOAD_LDFLAGS_COMMON_LINUX) @FLAG_M64@ PRELOAD_LDFLAGS_PPC32_LINUX = $(PRELOAD_LDFLAGS_COMMON_LINUX) @FLAG_M32@ Index: exp-drd/drd_pthread_intercepts.c =================================================================== --- exp-drd/drd_pthread_intercepts.c (revision 7862) +++ exp-drd/drd_pthread_intercepts.c (working copy) @@ -83,7 +83,7 @@ /* Function declarations. */ -void _init(void); +static void init(void) __attribute__((constructor)); static void check_threading_library(void); static void vg_set_main_thread_state(void); @@ -94,7 +94,7 @@ * after dlopen() has loaded the shared library. This function must not * be declared static. */ -void _init(void) +static void init(void) { check_threading_library(); vg_set_main_thread_state(); |
|
From: Bart V. A. <bar...@gm...> - 2008-04-06 07:49:31
|
On Sun, Apr 6, 2008 at 9:32 AM, Tom Hughes <to...@co...> wrote:
> That description is incorrect, or at least misleading.
>
> It never actually says that constructors don't work in shared
> objects (they do) it just implies that by saying that they are
> run before main is entered.
>
> That is only true for constructors in the main executable and
> any shared objects it is linked against however - constructors
> in a shared object that it dlopened will be run when the object
> is first opened.
>
> In short that attribute is doing something, and shouldn't be
> removed.
Thanks for the info, I wasn't aware that __attribute__((constructor))
should work in shared objects. By this time I had a look at the
dlopen() man page, and found the following paragraph:
Using ... the gcc -nostartfiles or -nostdlib options, is
not recommended. Their use may result in undesired behavior, since the
constructor/destructor routines will not be executed (unless special
measures are taken).
Is it correct that preloaded Valgrind shared objects are linked with
-nostdlib ? I noticed that
all Valgrind tools still work fine if I apply the following patch:
Index: coregrind/m_replacemalloc/vg_replace_malloc.c
===================================================================
@@ -668,6 +680,11 @@
0, 0, 0, 0);
}
+#include <stdlib.h>
+static void test(void) __attribute__((constructor));
+void test(void)
+{ abort(); }
+
/*--------------------------------------------------------------------*/
/*--- end vg_replace_malloc.c ---*/
/*--------------------------------------------------------------------*/
Bart.
|
|
From: Julian S. <js...@ac...> - 2008-04-09 20:09:41
|
> Using ... the gcc -nostartfiles or -nostdlib options, is > not recommended. Their use may result in undesired behavior, since > the constructor/destructor routines will not be executed (unless special > measures are taken). > > Is it correct that preloaded Valgrind shared objects are linked with > -nostdlib ? I put that in there in an attempt to minimise the dependencies on other shared libraries. Earlier in the life of the project there was much hassle caused by shared library dependencies, and ruthlessly removing dynamic linking as much as possible helped a lot. So I try to avoid shared library dependencies as much as possible now. What is the reason for wanting a change in link flags on these shared objects? J |
|
From: Bart V. A. <bar...@gm...> - 2008-04-10 05:52:17
|
On Wed, Apr 9, 2008 at 10:05 PM, Julian Seward <js...@ac...> wrote: > > > Using ... the gcc -nostartfiles or -nostdlib options, is > > not recommended. Their use may result in undesired behavior, since > > the constructor/destructor routines will not be executed (unless special > > measures are taken). > > > > Is it correct that preloaded Valgrind shared objects are linked with > > -nostdlib ? > > I put that in there in an attempt to minimise the dependencies on > other shared libraries. Earlier in the life of the project there > was much hassle caused by shared library dependencies, and ruthlessly > removing dynamic linking as much as possible helped a lot. So I try > to avoid shared library dependencies as much as possible now. > > What is the reason for wanting a change in link flags on these shared > objects? The only way in exp-drd to have the initialization code run early enough is to let that code run at shared library load time. This is implemented now via an _init() function. This works, but this is not very portable. Replacing the _init() function by a constructor attribute and letting gcc generate an _init() function would enhance portability. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-04-11 16:25:55
|
On Wed, Apr 9, 2008 at 10:05 PM, Julian Seward <js...@ac...> wrote:
>
> > Using ... the gcc -nostartfiles or -nostdlib options, is
> > not recommended. Their use may result in undesired behavior, since
> > the constructor/destructor routines will not be executed (unless special
> > measures are taken).
> >
> > Is it correct that preloaded Valgrind shared objects are linked with
> > -nostdlib ?
>
> I put that in there in an attempt to minimise the dependencies on
> other shared libraries. Earlier in the life of the project there
> was much hassle caused by shared library dependencies, and ruthlessly
> removing dynamic linking as much as possible helped a lot. So I try
> to avoid shared library dependencies as much as possible now.
Are you aware that -nodefaultlibs does not link in any shared
libraries ? The ldd command reports the following information for
preload objects linked with -nodefaultlibs:
$ ldd memcheck/vgpreload_memcheck-amd64-linux.so
statically linked
Bart.
|