Menu
▾
▴
Re: [Valgrind-users] __builtin_new and its buddies
|
From: Josef W. <Jos...@gm...> - 2003-06-05 15:26:51
|
On Thursday 05 June 2003 16:34, Alex Ivershen wrote: > Josef, > > With the test classes, I am linking simply as "g++ -o TEST main.o > Classes2.95.3.o". The libgcc.a library seems to be correct to me - that was > built along with the compiler and never gave me any grief. You are saiying > that " Usually, __builtin_new is defined in "libstdc++-libc6.2-2.so.3" and > will be linked in by the runtime library." - however, libstdc++ in my > installation is STATIC, there is a specific requirement not to use any Ok. So this is the culprit, and makes sense: If the (static) linker detects a symbol in different libraries, it prefers symbols from shared libraries and lets the runtime linker do the resolving (this at least seems to be true because __builtin_new is defined as weak (W) in libgcc.a). Then your requirements (only static libs from the compiler) effectively prohibit the use of Valgrind for you. > shared compiler libraries. So, in static libstdc++ __builtin_new are "U" > symbols. The only place the program can pull the definitions from is > libgcc.a. I tried > "-nostdlibraries" swich to the compiler to prevent him from pulling it by > default, but then, of course, the app won't link, citing unresolved > symbols. > > Now, when you do "nm" on your test application, what is the symbol type for > "__builtin_new"? And I am guessing that "ldd" shows dependency on > "libstdc++-libc6.2-2.so.3" - the application expects to resolve it at > run-time from libstdc++ and Valgrind has a chance to intercept everyting, Yes. > right? So, the bottom line seems to be that if I use static libstdc++, I > am screwed? Ugh ... Sure. You can't use Valgrind with static linked binaries, and that seems to hold true with even partial static binaries (as you don't have a "libstdc++-libc6.2-2.so.3"). But perhaps you can link in a shared library of your own with __builtin_new, calling malloc. At least this would allow to run the application with Valgrind, or even better: Put valgrind.so into your link line! Josef > > Alex > > Josef Weidendorfer wrote: > > 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 > > -- > Alex G. Ivershen Inet Technologies, Inc. > Network Products Dept. 1500 N. Greenville Ave. > Inet Technologies Inc. Richardson, TX 75081 > Phone: +1-469-330-4295 USA > > "Computer games don't affect kids; I mean if Pac-Man affected us as kids, > we'd all be running around in darkened rooms, munching magic pills and > listening to repetitive electronic music." -- Kristian Wilson, Nintendo, > Inc |
