|
From: Rob H. <ti...@ge...> - 2005-08-17 11:02:32
|
Hi, As part of the format check code I need to replace printf with our own version which runs some sanity checks. I've happily managed to replace fprintf and some others, but not printf. Anyone know what's special about printf and why I can't replace it with VG_REPLACE_FUNCTION like I can the others? The output of 'valgrind --tool=3Dformatcheck --trace-redirs=3Dyes /tmp/test= ' looks the same whether I try to replace fprintf or printf (save the different function name obviously), but when trying to redirect the printf function my replacement isn't actually called :/ It's not helped that I don't quite understand the syntax of the trace-redirs report. It says it's loaded vg_preload_core.so and then lists some REDIRS including the (f)printf one which is in my preload library which it hasn't loaded yet, then it says it's loaded my preload, but there is no mention of the (f)printf redir which is there. If I remove the VG_REPLACE_FUNCTION from my code, it doesn't mention any (f)printf redirections, so I'm assuming there is no printf redirection in the core valgrind. Example: <header snipped> --30136-- Just loaded /tmp/a.out (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/ld-2.3.5.so (soname=3Dld-linux-x86-64.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600000 to 0x7002B2DB --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600000 -> 0x7002B2DB) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600000) -> 0x7002B2DB) --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600400 to 0x7002B2E5 --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600400 -> 0x7002B2E5) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600400) -> 0x7002B2E5) =3D=3D30136=3D=3D For more details, rerun with: -v =3D=3D30136=3D=3D=20 --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (soname=3Dvg_preload_core.so), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIR sym to addr: soname:libc.so.6:_Znwm to 0x25719C0F --30136-- REDIR sym to addr: soname:libstdc++*:builtin_new to 0x25719840 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_delete to 0x2571A821 --30136-- REDIR sym to addr: soname:libstdc++*:_ZnamRKSt9nothrow_t to 0x2571A124 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_new to 0x25719E18 --30136-- REDIR sym to addr: soname:libc.so.6:_ZnamRKSt9nothrow_t to 0x2571A1C7 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_new to 0x25719A89 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPvRKSt9nothrow_t to 0x2571A717 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPv to 0x2571A60D --30136-- REDIR sym to addr: soname:libstdc++*:_ZnwmRKSt9nothrow_t to 0x25719CD2 --30136-- REDIR sym to addr: soname:libc.so.6:memalign to 0x2571AC4E --30136-- REDIR sym to addr: soname:libc.so.6:_ZnwmRKSt9nothrow_t to 0x25719D75 --30136-- REDIR sym to addr: soname:libc.so.6:realloc to 0x2571AB63 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPv to 0x2571A92B --30136-- REDIR sym to addr: soname:libc.so.6:malloc_trim to 0x2571AE72 --30136-- REDIR sym to addr: soname:libc.so.6:free to 0x2571A2EF --30136-- REDIR sym to addr: soname:libstdc++*:malloc to 0x257196FA --30136-- REDIR sym to addr: soname:libc.so.6:mallopt to 0x2571AD2C --30136-- REDIR sym to addr: soname:libstdc++*:_Znam to 0x25719F9E --30136-- REDIR sym to addr: soname:libc.so.6:malloc_set_state to 0x2571AE96 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPvRKSt9nothrow_t to 0x2571A692 --30136-- REDIR sym to addr: soname:libc.so.6:cfree to 0x2571A3F9 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_delete to 0x2571A503 --30136-- REDIR sym to addr: soname:libstdc++*:free to 0x2571A26A --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_new to 0x25719EDB --30136-- REDIR sym to addr: soname:libc.so.6:valloc to 0x2571AD19 --30136-- REDIR sym to addr: soname:libc.so.6:malloc to 0x2571979D --30136-- REDIR sym to addr: soname:libc.so.6:mallinfo to 0x2571AEA8 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPv to 0x2571A588 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_new to 0x257199C6 --30136-- REDIR sym to addr: soname:libc.so.6:pvalloc to 0x2571AE4E --30136-- REDIR sym to addr: soname:libc.so.6:builtin_new to 0x25719903 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_delete to 0x2571A47E --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50 --30136-- REDIR sym to addr: soname:libc.so.6:calloc to 0x2571AABA --30136-- REDIR sym to addr: soname:libstdc++*:_Znwm to 0x25719B4C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_stats to 0x2571AE60 --30136-- REDIR sym to addr: soname:libstdc++*:cfree to 0x2571A374 --30136-- REDIR sym to addr: soname:libc.so.6:malloc_get_state to 0x2571AE84 --30136-- REDIR sym to addr: soname:libc.so.6:posix_memalign to 0x2571AD37 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_delete to 0x2571A79C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_usable_size to 0x2571AD80 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPvRKSt9nothrow_t to 0x2571AA35 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPvRKSt9nothrow_t to 0x2571A9B0 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPv to 0x2571A8A6 --30136-- REDIR sym to addr: soname:libc.so.6:_Znam to 0x2571A061 --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.so (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/tls/libc-2.3.5.so (soname=3Dlibc.so.6), --30136-- resolving any unresolved redirs with it --30136-- redir resolved (soname:libc.so.6:malloc_usable_size=3D0x2588FAC0 -> 0x2571AD80) --30136-- redir resolved (soname:libc.so.6:posix_memalign=3D0x25893CA0 -> 0x2571AD37) --30136-- redir resolved (soname:libc.so.6:malloc_get_state=3D0x258926A0 -> 0x2571AE84) --30136-- redir resolved (soname:libc.so.6:malloc_stats=3D0x25893170 -> 0x2571AE60) --30136-- redir resolved (soname:libc.so.6:calloc=3D0x25891EE0 -> 0x2571AABA) --30136-- redir resolved (soname:libc.so.6:printf=3D0x2586FE60 -> 0x2571AF50) --30136-- redir resolved (soname:libc.so.6:pvalloc=3D0x25893330 -> 0x2571AE4E) --30136-- redir resolved (soname:libc.so.6:mallinfo=3D0x258930B0 -> 0x2571AEA8) --30136-- redir resolved (soname:libc.so.6:malloc=3D0x25892210 -> 0x2571979D) --30136-- redir resolved (soname:libc.so.6:valloc=3D0x25893430 -> 0x2571AD19) --30136-- redir resolved (soname:libc.so.6:malloc_set_state=3D0x25893520 -> 0x2571AE96) --30136-- redir resolved (soname:libc.so.6:mallopt=3D0x25893010 -> 0x2571AD2C) --30136-- redir resolved (soname:libc.so.6:free=3D0x25890630 -> 0x2571A2EF) --30136-- redir resolved (soname:libc.so.6:malloc_trim=3D0x2588FE70 -> 0x2571AE72) --30136-- redir resolved (soname:libc.so.6:realloc=3D0x25892860 -> 0x2571AB63) --30136-- redir resolved (soname:libc.so.6:memalign=3D0x258924B0 -> 0x2571AC4E) --30136-- Finished resolving --30136-- Just loaded /lib64/libdl-2.3.5.so (soname=3Dlibdl.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving foo =3D=3D30136=3D=3D The code is of course available should anyone feel it would be helpful, but as it works fine for fprintf I'm assuming the code is ok and that printf is "special" in some way I'm unaware of. Thanks, Rob --=20 - Rob Holland [ Gentoo Audit Team ] |
|
From: Tom H. <to...@co...> - 2005-08-17 11:50:10
|
In message <1124276546.3197.16.camel@localhost.localdomain>
Rob Holland <ti...@ge...> wrote:
> I've happily managed to replace fprintf and some others, but not
> printf.
That's odd, because I can see printf being replace in your log output
but not fprintf...
> Anyone know what's special about printf and why I can't replace it with
> VG_REPLACE_FUNCTION like I can the others?
You probably just haven't go the right name or something.
> It's not helped that I don't quite understand the syntax of the
> trace-redirs report.
I'll insert some comments to explain it...
> --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (soname=vg_preload_core.so),
We've loaded the preload library. Why is it vg_preload_core by the
way? Surely it should be vgpreload_<tool>.so?
> --30136-- resolving any unresolved redirs with it
> --30136-- Finished resolving
We checked if there were redirections pending for any symbols in
that library and (as expected) there weren't.
> --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50
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.
> --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.so (soname=(null)),
Now we've loaded your tool preload library but it doesn't seem to
contain any redirections.
> --30136-- Just loaded /lib64/tls/libc-2.3.5.so (soname=libc.so.6),
Now we've loaded libc...
> --30136-- resolving any unresolved redirs with it
...and started resolving any pending redirections in it...
> --30136-- redir resolved (soname:libc.so.6:printf=0x2586FE60 -> 0x2571AF50)
...and found that pending redirection for printf and resolved it so
any call to printf should now get redirected.
> The code is of course available should anyone feel it would be helpful,
> but as it works fine for fprintf I'm assuming the code is ok and that
> printf is "special" in some way I'm unaware of.
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?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-17 13:14:43
|
On Wed, 17 Aug 2005, Tom Hughes wrote: > We've loaded the preload library. Why is it vg_preload_core by the > way? Surely it should be vgpreload_<tool>.so? That's the preload file for the core, which is always loaded for every tool. It currently only contains the redirection for libc_freeres. > 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? I've seen names like _io_printf come up for these functions before. I suggest you try redirecting some other functions, and if they work see if you can work out the differences... the printf functions can be implemented strangely. And posting your code may help. N |
|
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 |
|
From: Tom H. <to...@co...> - 2005-08-17 12:24:20
|
In message <1124280839.7051.7.camel@localhost.localdomain>
Rob Holland <ti...@ge...> wrote:
> 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:
>>
>>
>> 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
>>
>> We checked if there were redirections pending for any symbols in
>> that library and (as expected) there weren't.
>>
>> > --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50
>>
>> 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=memcheck
> --trace-redir=yes ls'. You'll see there is no mention of printf.
>
> Now if I do 'valgrind --tool=formatcheck --trace-redir=yes ls' I do see
> a prinf redirection, but "in the wrong place" (i.e. attributed to
> valgrind_preload_core.so).
It's all right. I misunderstood the output - the "REDIR sym to addr"
lines are actually printed before it reports having loaded the library
so they apply to the library after not the one before.
So it all looks fine...
>> 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.
It would seem that way... I take it nm on libc only shows one printf
and not multiple versions? Even better use objdump -T which will show
the versions. In libc 2.3.4 I am only seeing one version of printf
and fprintf certainly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|