Menu
▾
▴
[Valgrind-users] unsubscribe
|
From: Roland V. P. <rol...@wa...> - 2003-06-08 13:50:15
|
unsubscribe ----- Original Message ----- From: <val...@li...> To: <val...@li...> Sent: Friday, June 06, 2003 12:41 PM Subject: Valgrind-users digest, Vol 1 #84 - 9 msgs > Send Valgrind-users mailing list submissions to > val...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/valgrind-users > or, via email, send a message with subject or body 'help' to > val...@li... > > You can reach the person managing the list at > val...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Valgrind-users digest..." > > > Today's Topics: > > 1. Re: __builtin_new and its buddies (Josef Weidendorfer) > 2. Re: __builtin_new and its buddies (Alex Ivershen) > 3. Re: __builtin_new and its buddies (Josef Weidendorfer) > 4. Re: __builtin_new and its buddies (Alex Ivershen) > 5. Pre-instrumented vs JIT instrumentation (Mike Bresnahan) > 6. Re: Pre-instrumented vs JIT instrumentation (Alex Ivershen) > 7. Re: Pre-instrumented vs JIT instrumentation (Mike Bresnahan) > 8. Re: Pre-instrumented vs JIT instrumentation (Nicholas Nethercote) > 9. Problem with libpthread.. (Joshua Moore-Oliva) > > --__--__-- > > Message: 1 > From: Josef Weidendorfer <Jos...@gm...> > To: Alex Ivershen <ale...@in...> > Subject: Re: [Valgrind-users] __builtin_new and its buddies > Date: Thu, 5 Jun 2003 09:56:29 +0200 > Cc: val...@li... > > 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 > > > --__--__-- > > Message: 2 > Date: Thu, 05 Jun 2003 09:34:02 -0500 > From: Alex Ivershen <ale...@in...> > To: Josef Weidendorfer <Jos...@gm...> > CC: val...@li... > Subject: Re: [Valgrind-users] __builtin_new and its buddies > > Sm9zZWYsDQoNCldpdGggdGhlIHRlc3QgY2xhc3NlcywgSSBhbSBsaW5raW5nIHNpbXBseSBh > cyAiZysrIC1vIFRFU1QgbWFpbi5vDQpDbGFzc2VzMi45NS4zLm8iLiBUaGUgbGliZ2NjLmEg > bGlicmFyeSBzZWVtcyB0byBiZSBjb3JyZWN0IHRvIG1lIC0gdGhhdCB3YXMNCmJ1aWx0IGFs > b25nIHdpdGggdGhlIGNvbXBpbGVyIGFuZCBuZXZlciBnYXZlIG1lIGFueSBncmllZi4gIFlv > dSBhcmUgc2FpeWluZyB0aGF0DQoiIFVzdWFsbHksIF9fYnVpbHRpbl9uZXcgaXMgZGVmaW5l > ZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBhbmQgd2lsbCBiZQ0KbGlua2VkIGlu > IGJ5IHRoZSBydW50aW1lIGxpYnJhcnkuIiAtIGhvd2V2ZXIsIGxpYnN0ZGMrKyBpbiBteSBp > bnN0YWxsYXRpb24gaXMNClNUQVRJQywgdGhlcmUgaXMgYSBzcGVjaWZpYyByZXF1aXJlbWVu > dCBub3QgdG8gdXNlIGFueSBzaGFyZWQgY29tcGlsZXINCmxpYnJhcmllcy4gU28sIGluIHN0 > YXRpYyBsaWJzdGRjKysgX19idWlsdGluX25ldyBhcmUgIlUiIHN5bWJvbHMuIFRoZSBvbmx5 > IHBsYWNlDQp0aGUgcHJvZ3JhbSBjYW4gcHVsbCB0aGUgZGVmaW5pdGlvbnMgZnJvbSBpcyBs > aWJnY2MuYS4gIEkgdHJpZWQNCiItbm9zdGRsaWJyYXJpZXMiIHN3aWNoIHRvIHRoZSBjb21w > aWxlciB0byBwcmV2ZW50IGhpbSBmcm9tIHB1bGxpbmcgaXQgYnkNCmRlZmF1bHQsIGJ1dCB0 > aGVuLCBvZiBjb3Vyc2UsIHRoZSBhcHAgd29uJ3QgbGluaywgY2l0aW5nICB1bnJlc29sdmVk > IHN5bWJvbHMuDQoNCk5vdywgd2hlbiB5b3UgZG8gIm5tIiBvbiB5b3VyIHRlc3QgYXBwbGlj > YXRpb24sIHdoYXQgaXMgdGhlIHN5bWJvbCB0eXBlIGZvcg0KIl9fYnVpbHRpbl9uZXciPyAg > QW5kIEkgYW0gZ3Vlc3NpbmcgdGhhdCAibGRkIiBzaG93cyBkZXBlbmRlbmN5IG9uDQoibGli > c3RkYysrLWxpYmM2LjItMi5zby4zIiAtIHRoZSBhcHBsaWNhdGlvbiBleHBlY3RzIHRvIHJl > c29sdmUgaXQgYXQgcnVuLXRpbWUNCmZyb20gbGlic3RkYysrIGFuZCBWYWxncmluZCBoYXMg > YSBjaGFuY2UgdG8gaW50ZXJjZXB0IGV2ZXJ5dGluZywgcmlnaHQ/ICBTbywgdGhlDQpib3R0 > b20gbGluZSBzZWVtcyB0byBiZSB0aGF0IGlmIEkgdXNlIHN0YXRpYyBsaWJzdGRjKyssIEkg > YW0gc2NyZXdlZD8gVWdoIC4uLg0KDQpBbGV4DQoNCg0KSm9zZWYgV2VpZGVuZG9yZmVyIHdy > b3RlOg0KDQo+IE9uIFRodXJzZGF5IDA1IEp1bmUgMjAwMyAwMDo1MiwgQWxleCBJdmVyc2hl > biB3cm90ZToNCj4gPiA8IWRvY3R5cGUgaHRtbCBwdWJsaWMgIi0vL3czYy8vZHRkIGh0bWwg > NC4wIHRyYW5zaXRpb25hbC8vZW4iPg0KPiA+IDxodG1sPg0KPiA+IEdlbnRsZW1lbiwNCj4g > PiA8cD5JIGFtIHN0aWxsIGhhdmluZyBpc3N1ZXMgd2l0aCBfX2J1aWx0aW5fbmV3IG5vdCBi > ZWluZyBpbnRlcmNlcHRlZCBieQ0KPiA+IFZhbGdyaW5kLiZuYnNwOyBKZXJlbXkgRml0emhh > cmRpbmdlIGdhdmUgbWUgc29tZSBzdWdnZXN0aW9ucywgYnV0IGl0IGRpZA0KPiA+IG5vdCBz > b2x2ZSB0aGUgaXNzdWUuIEhlcmUgaXMgdGhlIHByb2JsZW06IHdoZW4gSSBhbSBjb21wbGlu > ZyBjZXJ0YWluDQo+ID4gY2xhc3NlcywgdGhlIGNvbXBpbGVyIGdlbmVyYXRlcyByZWZlcmVu > Y2VzIHRvIF9fYnVpbHRpbl9uZXcgKHZlY19uZXcsDQo+ID4gZGVsZXRlLCB2ZWNfZGVsZXRl > KSBpbiB0aGUgb2JqZWN0IGZpbGUuJm5ic3A7IFdoZW4gdGhpcyBvYmplY3QgZmlsZSBpcw0K > PiA+IGxpbmtlZCBpbnRvIGV4ZWN1dGFibGUsIHRoZSBjb21waWxlciByZXNvbHZlcyB0aGUg > X19idWlsdGluKiByZWZlcmVuY2VzDQo+ID4gZnJvbSBsaWJnY2MuYSwgd2hlcmUgdGhleSBh > cmUgZGVmaW5lZCBhcyAiVyIgc3ltYm9scy4NCj4gPiA8cD5BcyBhIHJlc3VsdCwmbmJzcDsg > VmFsZ3JpbmQgZG9lcyBOT1QgaW50ZXJjZXB0IHRob3NlIF9fYnVpbHRpbioNCj4gPiBmdW5j > dGlvbnMsIGFuZCBvbmx5IGNhdGNoZXMgbWFsbG9jKCkgYW5kIGZyZWUoKSBjYWxscyB3aGVu > IHRoZXNlIGNsYXNzZXMNCj4gPiBhcmUgdXNlZC4gQXMgeW91IGNhbiBpbWFnaW5lLCBhIHN3 > YXJtIG9mIG11c21hdGNoZWQgZnJlZS9kZWxldGUvZGVsZXRlW10gaXMNCj4NCj4gWW91ciBv > YmplY3QgZmlsZXMgc2VlbSB0byBiZSBmaW5lLg0KPiBUaGUgcHJvYmxlbSBpcywgdGhhdCB0 > aGUgc3RhdGljIGxpbmsgcHJvY2VzcyBzaG91bGRuJ3QgcmVzb2x2ZSBfX2J1aWx0aW5fbmV3 > LA0KPiBpLmUuIHRoZSBsaWJnY2MuYSB5b3UgbWVudGlvbiBzZWVtcyB0byBiZSB3cm9uZywg > aWYgaXQgcmVhbGx5IGRlZmluZXMNCj4gX19idWlsdGluX25ldyBzdGF0aWNhbGx5LiBQZXJo > YXBzIHRoaXMgZmlsZSBzaG91bGRuJ3QgYmUgbGlua2VkIGluIG9yIGlzIGZyb20NCj4gYSB3 > cm9uZyBjb21waWxlciB2ZXJzaW9uPyBPciB5b3UgZG8gc29tZSBwYXJ0aWFsIHN0YXRpYyBs > aW5raW5nLiBXaGF0J3MgeW91cg0KPiBsaW5rIGNvbW1hbmQgbGluZT8NCj4NCj4gSSBqdXN0 > IGNoZWNrZWQgd2l0aCBteSBvd24gaW5zdGFsbGF0aW9uIG9mIEdDQyAyLjk1LjMgKFN1c2U4 > LjEpLg0KPiBJZiBJIGNvbXBpbGUgeW91ciBDbGFzc2VzMi45NS4zLm8gd2l0aCBhIGR1bW15 > IG1haW4oKSwgaXQgbGlua3MgZmluZSwgYW5kIGluDQo+IHRoZSByZXN1bHRpbmcgZXhlY3V0 > YWJsZSwgdGhlcmUgKmlzKiB0aGUgc3ltYm9sIF9fYnVpbHRpbl9uZXcsIHNvIHRoZXJlIHdp > bGwNCj4gYmUgbm8gcHJvYmxlbSB3aXRoIHZhbGdyaW5kID8hPw0KPiBVc3VhbGx5LCAiX19i > dWlsdGluX25ldyIgaXMgZGVmaW5lZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBh > bmQgd2lsbCBiZQ0KPiBsaW5rZWQgaW4gYnkgdGhlIHJ1bnRpbWUgbGlicmFyeS4NCj4NCj4g > Sm9zZWYNCg0KLS0NCkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAgICAgICAgICAgICAgICAg > ICAgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJvZHVjdHMgRGVwdC4gICAg > ICAgICAgICAgICAgICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2ZS4NCkluZXQgVGVjaG5v > bG9naWVzIEluYy4gICAgICAgICAgICAgICAgICAgICAgUmljaGFyZHNvbiwgVFggNzUwODEN > ClBob25lOiArMS00NjktMzMwLTQyOTUgICAgICAgICAgICAgICAgICAgICAgVVNBDQoNCiJD > b21wdXRlciBnYW1lcyBkb24ndCBhZmZlY3Qga2lkczsgSSBtZWFuIGlmIFBhYy1NYW4gYWZm > ZWN0ZWQgdXMgYXMga2lkcywgd2UnZA0KYWxsIGJlIHJ1bm5pbmcgYXJvdW5kIGluIGRhcmtl > bmVkIHJvb21zLCBtdW5jaGluZyBtYWdpYyBwaWxscyBhbmQgbGlzdGVuaW5nIHRvDQpyZXBl > dGl0aXZlIGVsZWN0cm9uaWMgbXVzaWMuIiAtLSBLcmlzdGlhbiBXaWxzb24sIE5pbnRlbmRv > LCBJbmMNCg0KDQo= > > > --__--__-- > > Message: 3 > From: Josef Weidendorfer <Jos...@gm...> > To: Alex Ivershen <ale...@in...> > Subject: Re: [Valgrind-users] __builtin_new and its buddies > Date: Thu, 5 Jun 2003 17:19:50 +0200 > Cc: val...@li... > > 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 > > > > --__--__-- > > Message: 4 > Date: Thu, 05 Jun 2003 13:12:10 -0500 > From: Alex Ivershen <ale...@in...> > To: Josef Weidendorfer <Jos...@gm...> > CC: val...@li... > Subject: Re: [Valgrind-users] __builtin_new and its buddies > > Sm9zZWYsDQoNCkkgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgYXNzaXRhbmNlISBDbGVh > cmVkIHVwIHRoaW5ncyBmb3IgbWUgcXVpdGUgYSBiaXQuDQpXaGF0IEkgcmVzb3J0ZWQgdG8g > ZG9pbmcgaXMgYnVpbGRpbmcgYSBzaGFyZWQgbGlic3RkYysrIGxpYnJhcnkgYW5kIGZvcmNl > DQppbi1ob3VzZSBidWlsZHMgdG8gdXNlIHRoZSBzaGFyZWQgbGlicmFyeSBhbmQgZXh0ZXJu > YWwgcmVsZWFzZXMgdG8gbGluaw0Kc3RhdGljYWxseS4gIFZhbGdyaW5kIGlzIHdvcmtpbmcg > cGVyZmVjdGx5IHdpdGggc2hhcmVkIGxpYnN0ZGMrKy4gTWlnaHQgYmUgd29ydGgNCmFkZGlu > ZyB0byBWYWxncmluZCBGQVE/DQoNClRoYW5rcyBhZ2FpbiEgUmVnYXJkcywNCkFsZXgNCg0K > DQpKb3NlZiBXZWlkZW5kb3JmZXIgd3JvdGU6DQoNCj4gT24gVGh1cnNkYXkgMDUgSnVuZSAy > MDAzIDAwOjUyLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+IDwhZG9jdHlwZSBodG1sIHB1 > YmxpYyAiLS8vdzNjLy9kdGQgaHRtbCA0LjAgdHJhbnNpdGlvbmFsLy9lbiI+DQo+ID4gPGh0 > bWw+DQo+ID4gR2VudGxlbWVuLA0KPiA+IDxwPkkgYW0gc3RpbGwgaGF2aW5nIGlzc3VlcyB3 > aXRoIF9fYnVpbHRpbl9uZXcgbm90IGJlaW5nIGludGVyY2VwdGVkIGJ5DQo+ID4gVmFsZ3Jp > bmQuJm5ic3A7IEplcmVteSBGaXR6aGFyZGluZ2UgZ2F2ZSBtZSBzb21lIHN1Z2dlc3Rpb25z > LCBidXQgaXQgZGlkDQo+ID4gbm90IHNvbHZlIHRoZSBpc3N1ZS4gSGVyZSBpcyB0aGUgcHJv > YmxlbTogd2hlbiBJIGFtIGNvbXBsaW5nIGNlcnRhaW4NCj4gPiBjbGFzc2VzLCB0aGUgY29t > cGlsZXIgZ2VuZXJhdGVzIHJlZmVyZW5jZXMgdG8gX19idWlsdGluX25ldyAodmVjX25ldywN > Cj4gPiBkZWxldGUsIHZlY19kZWxldGUpIGluIHRoZSBvYmplY3QgZmlsZS4mbmJzcDsgV2hl > biB0aGlzIG9iamVjdCBmaWxlIGlzDQo+ID4gbGlua2VkIGludG8gZXhlY3V0YWJsZSwgdGhl > IGNvbXBpbGVyIHJlc29sdmVzIHRoZSBfX2J1aWx0aW4qIHJlZmVyZW5jZXMNCj4gPiBmcm9t > IGxpYmdjYy5hLCB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkIGFzICJXIiBzeW1ib2xzLg0KPiA+ > IDxwPkFzIGEgcmVzdWx0LCZuYnNwOyBWYWxncmluZCBkb2VzIE5PVCBpbnRlcmNlcHQgdGhv > c2UgX19idWlsdGluKg0KPiA+IGZ1bmN0aW9ucywgYW5kIG9ubHkgY2F0Y2hlcyBtYWxsb2Mo > KSBhbmQgZnJlZSgpIGNhbGxzIHdoZW4gdGhlc2UgY2xhc3Nlcw0KPiA+IGFyZSB1c2VkLiBB > cyB5b3UgY2FuIGltYWdpbmUsIGEgc3dhcm0gb2YgbXVzbWF0Y2hlZCBmcmVlL2RlbGV0ZS9k > ZWxldGVbXSBpcw0KPg0KPiBZb3VyIG9iamVjdCBmaWxlcyBzZWVtIHRvIGJlIGZpbmUuDQo+ > IFRoZSBwcm9ibGVtIGlzLCB0aGF0IHRoZSBzdGF0aWMgbGluayBwcm9jZXNzIHNob3VsZG4n > dCByZXNvbHZlIF9fYnVpbHRpbl9uZXcsDQo+IGkuZS4gdGhlIGxpYmdjYy5hIHlvdSBtZW50 > aW9uIHNlZW1zIHRvIGJlIHdyb25nLCBpZiBpdCByZWFsbHkgZGVmaW5lcw0KPiBfX2J1aWx0 > aW5fbmV3IHN0YXRpY2FsbHkuIFBlcmhhcHMgdGhpcyBmaWxlIHNob3VsZG4ndCBiZSBsaW5r > ZWQgaW4gb3IgaXMgZnJvbQ0KPiBhIHdyb25nIGNvbXBpbGVyIHZlcnNpb24/IE9yIHlvdSBk > byBzb21lIHBhcnRpYWwgc3RhdGljIGxpbmtpbmcuIFdoYXQncyB5b3VyDQo+IGxpbmsgY29t > bWFuZCBsaW5lPw0KPg0KPiBJIGp1c3QgY2hlY2tlZCB3aXRoIG15IG93biBpbnN0YWxsYXRp > b24gb2YgR0NDIDIuOTUuMyAoU3VzZTguMSkuDQo+IElmIEkgY29tcGlsZSB5b3VyIENsYXNz > ZXMyLjk1LjMubyB3aXRoIGEgZHVtbXkgbWFpbigpLCBpdCBsaW5rcyBmaW5lLCBhbmQgaW4N > Cj4gdGhlIHJlc3VsdGluZyBleGVjdXRhYmxlLCB0aGVyZSAqaXMqIHRoZSBzeW1ib2wgX19i > dWlsdGluX25ldywgc28gdGhlcmUgd2lsbA0KPiBiZSBubyBwcm9ibGVtIHdpdGggdmFsZ3Jp > bmQgPyE/DQo+IFVzdWFsbHksICJfX2J1aWx0aW5fbmV3IiBpcyBkZWZpbmVkIGluICJsaWJz > dGRjKystbGliYzYuMi0yLnNvLjMiIGFuZCB3aWxsIGJlDQo+IGxpbmtlZCBpbiBieSB0aGUg > cnVudGltZSBsaWJyYXJ5Lg0KPg0KPiBKb3NlZg0KDQotLQ0KQWxleCBHLiBJdmVyc2hlbiAg > ICAgICAgICAgICAgICAgICAgICAgICAgICBJbmV0IFRlY2hub2xvZ2llcywgSW5jLg0KTmV0 > d29yayBQcm9kdWN0cyBEZXB0LiAgICAgICAgICAgICAgICAgICAgICAxNTAwIE4uIEdyZWVu > dmlsbGUgQXZlLg0KSW5ldCBUZWNobm9sb2dpZXMgSW5jLiAgICAgICAgICAgICAgICAgICAg > ICBSaWNoYXJkc29uLCBUWCA3NTA4MQ0KUGhvbmU6ICsxLTQ2OS0zMzAtNDI5NSAgICAgICAg > ICAgICAgICAgICAgICBVU0ENCg== > > > --__--__-- > > Message: 5 > Reply-To: "Mike Bresnahan" <mbr...@vi...> > From: "Mike Bresnahan" <mbr...@vi...> > To: <Val...@li...> > Date: Thu, 5 Jun 2003 17:22:38 -0500 > Subject: [Valgrind-users] Pre-instrumented vs JIT instrumentation > > I am new to valgrind, but I have used Rational Quantify. Excuse if this is > a FAQ, but I could not find anything in the FAQ nor in the mailing list > archive. > > I am curious why valgrind chooses to instrument on-the-fly every time the > application is executed rather than instrumenting the application ahead of > time and reexecuting the same instrumented executable each time, a la > Quantify. To my perhaps naive mind it seems like instrumenting on-the-fly > is less efficient. Can someone lend some insight? > > Mike > > > > --__--__-- > > Message: 6 > Date: Thu, 05 Jun 2003 17:41:19 -0500 > From: Alex Ivershen <ale...@in...> > To: Mike Bresnahan <mbr...@vi...> > CC: Val...@li... > Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Valgrind, unlike Rational suite tools, does not "instrument" anything. > That's the beauty of it - you don't need to recompile (or in case ot Quantify > re-link) the application. The difference is that Rational tools embed > extra code inside your object files and libraries - for memory or performance > profiling. As a result, executable size, shared libraries sizes are huge > and executiion suffers greatly (esp. with purify). Valgrind, on the other > hand, runs your application on a synthetic CPU, all the machine instructions > of your app are executed by Valgrind on this CPU and memory/performance > profiling is done there, not in your app code. As far as Quantify > comparison, cachegrind sking gives you much more information - e.g. Quantify > does not report cache usage profile. > <p>Last but not least - Valgrind is free, has MUCH better developer > support, and is updated more frequently. > <br>Downside - only runs on x86 Linux, exactly because of synthetic CPU > - porting it to other platforms is too much work, so developers chose the > most popular platform. > <p>Regards, > <br>Alex > <p>Mike Bresnahan wrote: > <blockquote TYPE=CITE>I am new to valgrind, but I have used Rational Quantify. > Excuse if this is > <br>a FAQ, but I could not find anything in the FAQ nor in the mailing > list > <br>archive. > <p>I am curious why valgrind chooses to instrument on-the-fly every time > the > <br>application is executed rather than instrumenting the application ahead > of > <br>time and reexecuting the same instrumented executable each time, a > la > <br>Quantify. To my perhaps naive mind it seems like instrumenting > on-the-fly > <br>is less efficient. Can someone lend some insight? > <p>Mike > <p>------------------------------------------------------- > <br>This SF.net email is sponsored by: Etnus, makers of TotalView, > The best > <br>thread debugger on the planet. Designed with thread debugging features > <br>you've never dreamed of, try TotalView 6 free at www.etnus.com. > <br>_______________________________________________ > <br>Valgrind-users mailing list > <br>Val...@li... > <br><a href="https://lists.sourceforge.net/lists/listinfo/valgrind-users">https://l ists.sourceforge.net/lists/listinfo/valgrind-users</a></blockquote> > > <pre>-- > Alex G. Ivershen &n bsp; Inet Technologies, Inc. > Network Products Dept.   ; 1500 N. Greenville Ave. > Inet Technologies Inc. Richardson, TX 75081 > Phone: +1-469-330-4295 & nbsp; 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</pre> > </html> > > > > --__--__-- > > Message: 7 > Reply-To: "Mike Bresnahan" <mbr...@vi...> > From: "Mike Bresnahan" <mbr...@vi...> > To: <Val...@li...> > Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation > Date: Thu, 5 Jun 2003 18:00:15 -0500 > > Perhaps I misunderstand how valgrind works. I have the understanding that, > using the synthetic CPU, valgrind instruments the application on the fly and > stores the instrumented code blocks in a cache. The author describes this > process here http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html. > > Do I misunderstand? > > Note that Quanitfy for Windows does not require a relink. You just point it > at an executable and off it goes. First it instruments the executable and > dependent DLLs and then it executes it. The UNIX version requires a > relink - or at least it did when I last used it in the mid-1990's on HPUX. > > Mike Bresnahan > ----- Original Message ----- > From: "Alex Ivershen" <ale...@in...> > To: "Mike Bresnahan" <mbr...@vi...> > Cc: <Val...@li...> > Sent: Thursday, June 05, 2003 5:41 PM > Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation > > > > Valgrind, unlike Rational suite tools, does not "instrument" anything. > That's the beauty of it - you don't need to recompile (or in case ot > Quantify re-link) the application. The difference is that Rational tools > embed extra code inside your object files and libraries - for memory or > performance profiling. As a result, executable size, shared libraries sizes > are huge and executiion suffers greatly (esp. with purify). Valgrind, on the > other hand, runs your application on a synthetic CPU, all the machine > instructions of your app are executed by Valgrind on this CPU and > memory/performance profiling is done there, not in your app code. As far as > Quantify comparison, cachegrind sking gives you much more information - e.g. > Quantify does not report cache usage profile. > > Last but not least - Valgrind is free, has MUCH better developer support, > and is updated more frequently. > > Downside - only runs on x86 Linux, exactly because of synthetic CPU - > porting it to other platforms is too much work, so developers chose the most > popular platform. > > > > Regards, > > Alex > > > > --__--__-- > > Message: 8 > Date: Fri, 6 Jun 2003 10:08:11 +0100 (BST) > From: Nicholas Nethercote <nj...@ca...> > To: Mike Bresnahan <mbr...@vi...> > cc: Val...@li... > Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation > > On Thu, 5 Jun 2003, Mike Bresnahan wrote: > > > Perhaps I misunderstand how valgrind works. I have the understanding that, > > using the synthetic CPU, valgrind instruments the application on the fly and > > stores the instrumented code blocks in a cache. The author describes this > > process here http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html. > > > > Do I misunderstand? > > You are right, Valgrind instruments the app dynamically. > > I think when Alex said Valgrind doesn't "instrument" anything, he meant > that you don't have to do anything explicit, in a separate step. > > > Note that Quanitfy for Windows does not require a relink. You just point it > > at an executable and off it goes. First it instruments the executable and > > dependent DLLs and then it executes it. > > Valgrind's approach -- dynamically compiling and instrumenting all code > every time -- is the most convenient for users. No worrying about whether > an executable is instrumented or anything. > > As for efficiency, it would be possible to have Valgrind save the code it > generates, so you could reuse it the next time. But the dynamic > compilation + instrumentation phase typically only takes up about 10% of > the execution time for Valgrind (the Memcheck skin, at least) so doing > this wouldn't help performance much, but it would make the implementation > more complicated, and possibly make life more difficult for users. > > Actually, thinking more, Valgrind's just-in-time approach could has > another efficiency advantage -- it only instruments the code that gets > executed. This is good (especially space-wise) if you only use a small > fraction of a great big library. > > N > > > > > > > --__--__-- > > Message: 9 > From: Joshua Moore-Oliva <jo...@ch...> > To: val...@li... > Date: Fri, 6 Jun 2003 06:34:13 -0400 > Subject: [Valgrind-users] Problem with libpthread.. > > For a while I thought this was a glib libpthread prolem.. but when I noticed > > "/usr/lib/valgrind/libpthread.so" > > that libpthread was IN valgrind itself... I think it's got something to do > with valgrind. > > I created some thread specific data areas... starting at line 57 as per > valgrinds output I have > > /*LINE 57*/if ( pthread_key_create( &global_pthread_base_dir, free_base_dir ) > != 0 ) > printf( "File: %s. Line: %d. Error initialising key.\n", __FILE__, > __LINE__ ); > return 0; > } > > then before I exit the program I have > > if ( pthread_key_delete( global_pthread_base_dir ) != 0 ) { > printf( "File: %s. Line: %d. Error deleting key.\n", __FILE__, __LINE__ > ); > return 0; > } > > > When I exit I notice that it appears there is a debug libpthread being used... > So I'm thinking the problem is in valgrind debug pthread libraries itself. > > Or is it me? > > 200 bytes in 1 blocks are still reachable in loss record 1 of 1 > ==17060== at 0x40215D2B: my_malloc (in /usr/lib/valgrind/libpthread.so) > ==17060== by 0x402178A2: get_or_allocate_specifics_ptr (in > /usr/lib/valgrind/libpthread.so) > ==17060== by 0x402179D5: __pthread_key_create (in > /usr/lib/valgrind/libpthread.so) > ==17060== by 0x805612C: main (main.c:57) > ==17060== by 0x4028CDC3: __libc_start_main (in /lib/libc-2.3.1.so) > ==17060== by 0x804BB90: (within > /home/chatgris/code/mastermailings/code/daemons/list_manager/list_manager) > > Josh > > > > > --__--__-- > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > End of Valgrind-users Digest > |
