Menu
▾
▴
Re: [Valgrind-users] __builtin_new and its buddies
|
From: Josef W. <Jos...@gm...> - 2003-06-05 07:57:47
|
On Thursday 05 June 2003 00:52, Alex Ivershen wrote: > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Gentlemen, > <p>I am still having issues with __builtin_new not being intercepted by > Valgrind. Jeremy Fitzhardinge gave me some suggestions, but it did > not solve the issue. Here is the problem: when I am compling certain > classes, the compiler generates references to __builtin_new (vec_new, > delete, vec_delete) in the object file. When this object file is > linked into executable, the compiler resolves the __builtin* references > from libgcc.a, where they are defined as "W" symbols. > <p>As a result, Valgrind does NOT intercept those __builtin* > functions, and only catches malloc() and free() calls when these classes > are used. As you can imagine, a swarm of musmatched free/delete/delete[] is Your object files seem to be fine. The problem is, that the static link process shouldn't resolve __builtin_new, i.e. the libgcc.a you mention seems to be wrong, if it really defines __builtin_new statically. Perhaps this file shouldn't be linked in or is from a wrong compiler version? Or you do some partial static linking. What's your link command line? I just checked with my own installation of GCC 2.95.3 (Suse8.1). If I compile your Classes2.95.3.o with a dummy main(), it links fine, and in the resulting executable, there *is* the symbol __builtin_new, so there will be no problem with valgrind ?!? Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and will be linked in by the runtime library. Josef |
