|
From: Rob H. <ti...@ge...> - 2005-08-17 12:14:06
|
On Wed, 2005-08-17 at 12:50 +0100, Tom Hughes wrote: > In message <1124276546.3197.16.camel@localhost.localdomain> > Rob Holland <ti...@ge...> wrote: >=20 > > I've happily managed to replace fprintf and some others, but not > > printf. >=20 > That's odd, because I can see printf being replace in your log output > but not fprintf... In this case I had stripped out fprintf stuff and was trying to just replace printf. > You probably just haven't go the right name or something. The right name of what though? :/ I have the right soname (fprintf works fine) and I'm pretty sure I spelt printf correctly :) There is nothing else to get wrong :/ > I'll insert some comments to explain it... >=20 > > --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (son= ame=3Dvg_preload_core.so), >=20 > We've loaded the preload library. Why is it vg_preload_core by the > way? Surely it should be vgpreload_<tool>.so? Valgrind loads/names that itself, it's nothing to do with me :) > > --30136-- resolving any unresolved redirs with it > > --30136-- Finished resolving >=20 > We checked if there were redirections pending for any symbols in > that library and (as expected) there weren't. >=20 > > --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50 >=20 > We found a redirection for printf in the vg_preload_core.so library > but as libc has not been loaded yet we can't resolve it. No we can't have done, because there isn't one... valgrind doesn't do any redirection for printf itself. Try: 'valgrind --tool=3Dmemcheck --trace-redir=3Dyes ls'. You'll see there is no mention of printf. Now if I do 'valgrind --tool=3Dformatcheck --trace-redir=3Dyes ls' I do see a prinf redirection, but "in the wrong place" (i.e. attributed to valgrind_preload_core.so). > > --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.s= o (soname=3D(null)), >=20 > Now we've loaded your tool preload library but it doesn't seem to > contain any redirections. It does, it has one for printf. > ...and found that pending redirection for printf and resolved it so > any call to printf should now get redirected. And yet it doesn't :/ > Are you sure your test program is actually calling printf and that gcc > and/or the glibc headers haven't turned it into a call to some other > routine? Well, the only thing I have to go on really is nm output. nm is the same for printf and fprintf and both look like they have undefined symbols against glibc, which would imply they would be resolved the same way to me. Cheers, Rob --=20 |