|
From: Chengnian S. <che...@ya...> - 2009-02-17 12:00:52
|
Hi all,
Is it possible to get the types and values of arguments with Valgrind?
I would like to instrument applications to get the execution trace including the functions called and their argument values and types.
Thanks so much.
Best regards.
Chengnian Sun.
|
|
From: Nicholas N. <n.n...@gm...> - 2009-02-17 23:25:13
|
On Tue, Feb 17, 2009 at 11:00 PM, Chengnian Sun <che...@ya...> wrote: > > Is it possible to get the types and values of arguments with Valgrind? It's difficult to do at the binary level. You probably need debug info to know what args a function is expecting, you probably can't just tell from the instruction stream. > I would like to instrument applications to get the execution trace including > the functions called and their argument values and types. The Callgrind tool is able to trace function entry/exit. And the --read-var-info option causes debug info for stack variables to be read. It might be possible to combine the two to get what you want, but it would require non-trivial effort. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-18 20:15:23
|
On Thu, Feb 19, 2009 at 6:36 AM, Josef Weidendorfer <Jos...@gm...> wrote: > > . . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40] > . . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40] > . . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380] > . . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f] > . . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0] > . . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f] > . . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00] > . . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f] > . . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0] > . . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40] > . . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460] > ... > > If somebody can derive enough information from debug info to allow for output similar > to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own > tool "vtrace". I just tried this on the simple program 'date' and got lots of lines like this: . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210] [and 1000s more lines like it] What's happening there? And what does the "..." mean? (I looked in the manual but didn't see anything about this.) N |
|
From: Josef W. <Jos...@gm...> - 2009-02-18 20:34:09
|
On Wednesday 18 February 2009, Nicholas Nethercote wrote:
> On Thu, Feb 19, 2009 at 6:36 AM, Josef Weidendorfer
> <Jos...@gm...> wrote:
> >
> > . . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40]
> > . . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40]
> > . . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380]
> > . . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> > . . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0]
> > . . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> > . . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00]
> > . . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f]
> > . . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0]
> > . . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40]
> > . . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460]
> > ...
> >
> > If somebody can derive enough information from debug info to allow for output similar
> > to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own
> > tool "vtrace".
>
> I just tried this on the simple program 'date' and got lots of lines like this:
>
> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> [and 1000s more lines like it]
>
> What's happening there?
Indead, that looks quite strange. What architecture is this?
("valgrind --tool=callgrind --ct-verbose=1 date" looks reasonable here on x86).
It could be a case of a loop going back to the function entry, and callgrind
assuming tail recursion, but that doesn't make sense here.
> And what does the "..." mean?
The hex numbers after "strcmp(" are 32bit values which happen to appear on
the stack, and on x86 this matched the first two parameters last time
I checked. The "..." just is a hint that callgrind actually is clueless about the
number of parameters.
> (I looked in
> the manual but didn't see anything about this.)
Yes, as you see above, there is a reason for this. It just is meant as internal
unstable debugging aid, which happens to work sometimes on some architecture.
Josef
>
> N
>
|
|
From: Chengnian S. <che...@ya...> - 2009-02-19 07:41:04
|
I have a question. How much information I could get from the debug-info ?
Is it enough to get argument type?
Thanks.
Best regards.
Chengnian Sun.
________________________________
From: Josef Weidendorfer <Jos...@gm...>
To: val...@li...
Cc: Nicholas Nethercote <n.n...@gm...>; Chengnian Sun <che...@ya...>
Sent: Thursday, February 19, 2009 3:36:11 AM
Subject: Re: [Valgrind-users] get the types and values of arguments
On Tuesday 17 February 2009, Nicholas Nethercote wrote:
> On Tue, Feb 17, 2009 at 11:00 PM, Chengnian Sun <che...@ya...> wrote:
> >
> > Is it possible to get the types and values of arguments with Valgrind?
>
> It's difficult to do at the binary level. You probably need debug
> info to know what args a function is expecting, you probably can't
> just tell from the instruction stream.
>
> > I would like to instrument applications to get the execution trace including
> > the functions called and their argument values and types.
>
> The Callgrind tool is able to trace function entry/exit. And the
> --read-var-info option causes debug info for stack variables to be
> read. It might be possible to combine the two to get what you want,
> but it would require non-trivial effort.
There was some interest in the past regarding the debug output which callgrind
prints out with "--ct-verbose=1"; something like
....
. . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40]
. . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40]
. . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380]
. . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
. . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0]
. . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
. . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00]
. . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f]
. . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0]
. . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40]
. . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460]
....
If somebody can derive enough information from debug info to allow for output similar
to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own
tool "vtrace".
Josef
|
|
From: Josef W. <Jos...@gm...> - 2009-02-19 14:28:26
|
On Thursday 19 February 2009, Chengnian Sun wrote: > I have a question. How much information I could get from the debug-info? That depends on the debug info format used; I think you can concentrate on DWARF. You can check out in the specifiation what is available in principle, then look what a given compiler really provides, and then check whether Valgrinds debug readers and core retrieval funtions are enough for this task. For callgrind, I never did anything with debug info about data types, but that obviously whould be needed here. I always just used the service functions for debug info which are available in Valgrind core. AFAIK, Julian recently added some functions to get at variable name for a given stack address. You need it the other way around: get information about number of parameter and types, and how to access them. Josef > > Is it enough to get argument type? > > Thanks. > > Best regards. > > > Chengnian Sun. > > > > > ________________________________ > From: Josef Weidendorfer <Jos...@gm...> > To: val...@li... > Cc: Nicholas Nethercote <n.n...@gm...>; Chengnian Sun <che...@ya...> > Sent: Thursday, February 19, 2009 3:36:11 AM > Subject: Re: [Valgrind-users] get the types and values of arguments > > On Tuesday 17 February 2009, Nicholas Nethercote wrote: > > On Tue, Feb 17, 2009 at 11:00 PM, Chengnian Sun <che...@ya...> wrote: > > > > > > Is it possible to get the types and values of arguments with Valgrind? > > > > It's difficult to do at the binary level. You probably need debug > > info to know what args a function is expecting, you probably can't > > just tell from the instruction stream. > > > > > I would like to instrument applications to get the execution trace including > > > the functions called and their argument values and types. > > > > The Callgrind tool is able to trace function entry/exit. And the > > --read-var-info option causes debug info for stack variables to be > > read. It might be possible to combine the two to get what you want, > > but it would require non-trivial effort. > > There was some interest in the past regarding the debug output which callgrind > prints out with "--ct-verbose=1"; something like > > .... > . . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40] > . . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40] > . . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380] > . . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f] > . . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0] > . . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f] > . . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00] > . . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f] > . . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0] > . . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40] > . . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460] > .... > > If somebody can derive enough information from debug info to allow for output similar > to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own > tool "vtrace". > > Josef > > > |
|
From: Julian S. <js...@ac...> - 2009-02-19 14:50:18
|
> AFAIK, Julian recently added some functions to get at variable name for > a given stack address. You need it the other way around: get information > about number of parameter and types, and how to access them. Yes, that information (parameter names and types) is definitely in the Dwarf3, and the new reader I did (readdwarf3.c) could probably be extended to collect it. Unfortunately readdwarf3.c is what you could call a complicated nightmare, so it might not be easy to make the extension. Certainly studying the Dwarf3 spec would be helpful. Another important question is to understand precisely what information you do need. I imagine it will be the locations of all parameters for the code addresses which are the entry points of functions. At the moment readdwarf3.c throws away information about variables that are in registers -- it only records info on variables that are in memory. The reason is that this was not required for the initial functionality (the exp-ptrcheck tool and to a lesser extent, Helgrind), and so that is definitely one thing that would need to be fixed. (Since on most platforms other than x86, at least some of the arguments are passed in registers.) J |
|
From: Chengnian S. <che...@ya...> - 2009-02-19 14:33:56
|
Hi Josef,
Thank you so much for your comments. I will read something on the debug format.
Best regards.
Chengnian Sun.
________________________________
From: Josef Weidendorfer <Jos...@gm...>
To: Chengnian Sun <che...@ya...>
Cc: val...@li...; Nicholas Nethercote <n.n...@gm...>
Sent: Thursday, February 19, 2009 10:27:36 PM
Subject: Re: [Valgrind-users] get the types and values of arguments
On Thursday 19 February 2009, Chengnian Sun wrote:
> I have a question. How much information I could get from the debug-info?
That depends on the debug info format used; I think you can concentrate
on DWARF. You can check out in the specifiation what is available in
principle, then look what a given compiler really provides, and then
check whether Valgrinds debug readers and core retrieval funtions are
enough for this task.
For callgrind, I never did anything with debug info about data types,
but that obviously whould be needed here. I always just used the service
functions for debug info which are available in Valgrind core.
AFAIK, Julian recently added some functions to get at variable name for
a given stack address. You need it the other way around: get information
about number of parameter and types, and how to access them.
Josef
>
> Is it enough to get argument type?
>
> Thanks.
>
> Best regards.
>
>
> Chengnian Sun.
>
>
>
>
> ________________________________
> From: Josef Weidendorfer <Jos...@gm...>
> To: val...@li...
> Cc: Nicholas Nethercote <n.n...@gm...>; Chengnian Sun <che...@ya...>
> Sent: Thursday, February 19, 2009 3:36:11 AM
> Subject: Re: [Valgrind-users] get the types and values of arguments
>
> On Tuesday 17 February 2009, Nicholas Nethercote wrote:
> > On Tue, Feb 17, 2009 at 11:00 PM, Chengnian Sun <che...@ya...> wrote:
> > >
> > > Is it possible to get the types and values of arguments with Valgrind?
> >
> > It's difficult to do at the binary level. You probably need debug
> > info to know what args a function is expecting, you probably can't
> > just tell from the instruction stream.
> >
> > > I would like to instrument applications to get the execution trace including
> > > the functions called and their argument values and types.
> >
> > The Callgrind tool is able to trace function entry/exit. And the
> > --read-var-info option causes debug info for stack variables to be
> > read. It might be possible to combine the two to get what you want,
> > but it would require non-trivial effort.
>
> There was some interest in the past regarding the debug output which callgrind
> prints out with "--ct-verbose=1"; something like
>
> ....
> . . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40]
> . . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40]
> . . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380]
> . . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> . . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0]
> . . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> . . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00]
> . . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f]
> . . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0]
> . . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40]
> . . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460]
> ....
>
> If somebody can derive enough information from debug info to allow for output similar
> to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own
> tool "vtrace".
>
> Josef
>
>
>
|
|
From: Chengnian S. <che...@ya...> - 2009-02-21 02:18:30
|
Sorry, I noticed this email just now.
Yes, as you said, it is a little difficult to read the source code, which is over 4000 lines. But I will start reading the spec at the same time.
I just want to print the function call traces, and for each function call, print the type and value of each function.
Thanks for your tip and useful information. :-)
Thanks
Best regards.
Chengnian Sun.
________________________________
From: Julian Seward <js...@ac...>
To: val...@li...
Cc: Josef Weidendorfer <Jos...@gm...>; Chengnian Sun <che...@ya...>
Sent: Thursday, February 19, 2009 10:50:05 PM
Subject: Re: [Valgrind-users] get the types and values of arguments
> AFAIK, Julian recently added some functions to get at variable name for
> a given stack address. You need it the other way around: get information
> about number of parameter and types, and how to access them.
Yes, that information (parameter names and types) is definitely in the
Dwarf3, and the new reader I did (readdwarf3.c) could probably be extended
to collect it. Unfortunately readdwarf3.c is what you could call a
complicated nightmare, so it might not be easy to make the extension.
Certainly studying the Dwarf3 spec would be helpful.
Another important question is to understand precisely what information
you do need. I imagine it will be the locations of all parameters
for the code addresses which are the entry points of functions.
At the moment readdwarf3.c throws away information about variables that
are in registers -- it only records info on variables that are in memory.
The reason is that this was not required for the initial functionality
(the exp-ptrcheck tool and to a lesser extent, Helgrind), and so that
is definitely one thing that would need to be fixed. (Since on most
platforms other than x86, at least some of the arguments are passed in
registers.)
J
|
|
From: Chengnian S. <che...@ya...> - 2009-02-21 02:26:33
|
Oops, typing error.
Sorry, I noticed this email just now.
Yes, as you said, it is a
little difficult to read the readdwarf3.c, which is over 4000 lines. But
I will start reading the spec at the same time and it is well coded.
I just want to print the function call traces, and for each function call, print the types and values of all the arguments of each function.
Thanks for your tip and useful information. :-)
Best regards.
Chengnian Sun.
Best regards.
Chengnian Sun.
________________________________
From: Chengnian Sun <che...@ya...>
To: Julian Seward <js...@ac...>; val...@li...
Cc: Josef Weidendorfer <Jos...@gm...>
Sent: Saturday, February 21, 2009 10:13:25 AM
Subject: Re: [Valgrind-users] get the types and values of arguments
Sorry, I noticed this email just now.
Yes, as you said, it is a little difficult to read the source code, which is over 4000 lines. But I will start reading the spec at the same time.
I just want to print the function call traces, and for each function call, print the type and value of each function.
Thanks for your tip and useful information. :-)
Thanks
Best regards.
Chengnian Sun.
________________________________
From: Julian Seward <js...@ac...>
To: val...@li...
Cc: Josef Weidendorfer <Jos...@gm...>; Chengnian Sun <che...@ya...>
Sent: Thursday, February 19, 2009 10:50:05 PM
Subject: Re: [Valgrind-users] get the types and values of arguments
> AFAIK, Julian recently added some functions to get at variable name for
> a given stack address. You need it the other way around: get information
> about number of parameter and types, and how to access them.
Yes, that information (parameter names and types) is definitely in the
Dwarf3, and the new reader I did (readdwarf3.c) could probably be extended
to collect it. Unfortunately readdwarf3.c is what you could call a
complicated nightmare, so it might not be easy to make the extension.
Certainly studying the Dwarf3 spec would be helpful.
Another important question is to understand precisely what information
you do need. I imagine it will be the locations of all parameters
for the code addresses which are the entry points of functions.
At the moment readdwarf3.c throws away information about variables that
are in registers -- it only records info on variables that are in memory.
The reason is that this was not required for the initial functionality
(the exp-ptrcheck tool and to a lesser extent, Helgrind), and so that
is definitely one thing that would need to be fixed. (Since on most
platforms other than x86, at least some of the arguments are passed in
registers.)
J
|
|
From: Nicholas N. <n.n...@gm...> - 2009-02-21 03:03:11
|
On Thu, Feb 19, 2009 at 7:33 AM, Josef Weidendorfer
<Jos...@gm...> wrote:
>>
>> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
>> [and 1000s more lines like it]
>>
>> What's happening there?
>
> Indead, that looks quite strange. What architecture is this?
> ("valgrind --tool=callgrind --ct-verbose=1 date" looks reasonable here on x86).
It's amd64/Linux.
Nick
|
|
From: Josef W. <Jos...@gm...> - 2009-02-23 11:15:56
|
On Saturday 21 February 2009, Nicholas Nethercote wrote:
> On Thu, Feb 19, 2009 at 7:33 AM, Josef Weidendorfer
> <Jos...@gm...> wrote:
> >>
> >> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> >> [and 1000s more lines like it]
> >>
> >> What's happening there?
> >
> > Indead, that looks quite strange. What architecture is this?
> > ("valgrind --tool=callgrind --ct-verbose=1 date" looks reasonable here on x86).
>
> It's amd64/Linux.
Ok.
The inner loop of strcmp() on amd64 jumps back to the start of the function;
following machine code is from glibc 2.7, therefore the relative address does not match
your output, but it is obviously the same "issue":
000000000007aae0 <strcmp>:
7aae0: 8a 07 mov (%rdi),%al
7aae2: 3a 06 cmp (%rsi),%al
7aae4: 75 0d jne 7aaf3 <strcmp+0x13>
7aae6: 48 ff c7 inc %rdi
7aae9: 48 ff c6 inc %rsi
7aaec: 84 c0 test %al,%al
7aaee: 75 f0 jne 7aae0 <strcmp>
7aaf0: 31 c0 xor %eax,%eax
7aaf2: c3 retq
7aaf3: b8 01 00 00 00 mov $0x1,%eax
7aaf8: b9 ff ff ff ff mov $0xffffffff,%ecx
7aafd: 0f 42 c1 cmovb %ecx,%eax
7ab00: c3 retq
Callgrind assumes tail recursion optimized by the compiler, and shows the
jump back to the start as a recursive call. In this case, the heuristic is
a bit misguided. But it really could be that strcmp is coded using tail
recursion.
If you know a better heuristic, please tell me. The best probably would be
something similar to the suppression system used by memcheck, to specify
the interpretation of the code for a given function.
The strange values after "strcmp( ..." just show random content from the stack,
as strcmp() does not use the stack, but passes all arguments in registers.
So apart from the misguided heuristic, the output is expected.
Josef
>
> Nick
>
|