|
From: Siddharth N. <si...@gm...> - 2012-01-16 14:32:15
|
Hi All, I have written a small extension to callgrind to do some tracking of memory addresses accessed in functions. My function simply looks at the current state and determines in which function execution is currently happening. Then it builds and maintains its own data structures. This has worked fine so far. I want to take this further and also look at the execution context that Callgrind provides for the current BB being instrumented. However, from examination using gdb, I noticed that whatever program I run under Callgrind, the CLG_(current_state)->cxt->size is always 1 and CLG_(current_state)->cxt->fn[0] is the only valid entry. fn[1], fn[2] etc. never exist. my .gdbinit file: set env VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind file ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux handle SIGILL SIGSEGV nostop noprint b sim.c:1667 run --cache-sim=yes ./toy_prg Is there something possibly wrong with my setup or is this is a bug in Callgrind? Is anyone else seeing things differently. Siddharth Nilakantan |
|
From: Josef W. <Jos...@gm...> - 2012-01-16 16:31:48
|
Hi, On 16.01.2012 15:31, Siddharth Nilakantan wrote: > Hi All, > > I have written a small extension to callgrind to do some tracking of > memory addresses accessed in functions. My function simply looks at the > current state and determines in which function execution is currently > happening. Then it builds and maintains its own data structures. This > has worked fine so far. Cool. > I want to take this further and also look at the execution context that > Callgrind provides for the current BB being instrumented. However, from > examination using gdb, I noticed that whatever program I run under > Callgrind, the CLG_(current_state)->cxt->size is always 1 and > CLG_(current_state)->cxt->fn[0] is the only valid entry. fn[1], fn[2] > etc. never exist. Callgrind collects data for each execution context. If this always would include the full call chain, for a lot of programs, you would get a out-of-memory situation (e.g. firefox). Therefore, the default behavior is to only look at the current function for determination of the context. You can change this: * use e.g. "--separate-callers=5" to always use the last 5 entries in the call stack for the execution context. * use "--separate-callers5=foo" to specify for function "foo", how much call stack entries should be used for distinguish the execution context when running "foo" * use "--fn-skip=foo" to not change the execution context when calling into or leaving function foo Josef > > my .gdbinit file: > > set env VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind > file ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux > handle SIGILL SIGSEGV nostop noprint > b sim.c:1667 > run --cache-sim=yes ./toy_prg > > Is there something possibly wrong with my setup or is this is a bug in > Callgrind? Is anyone else seeing things differently. > > Siddharth Nilakantan > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Siddharth N. <si...@gm...> - 2012-01-16 18:53:16
|
Hi Josef, Thanks! That worked. Guess I missed it in the documentation. Siddharth On 16 January 2012 22:01, Josef Weidendorfer <Jos...@gm...>wrote: > Hi, > > On 16.01.2012 15:31, Siddharth Nilakantan wrote: > > Hi All, > > > > I have written a small extension to callgrind to do some tracking of > > memory addresses accessed in functions. My function simply looks at the > > current state and determines in which function execution is currently > > happening. Then it builds and maintains its own data structures. This > > has worked fine so far. > > Cool. > > > I want to take this further and also look at the execution context that > > Callgrind provides for the current BB being instrumented. However, from > > examination using gdb, I noticed that whatever program I run under > > Callgrind, the CLG_(current_state)->cxt->size is always 1 and > > CLG_(current_state)->cxt->fn[0] is the only valid entry. fn[1], fn[2] > > etc. never exist. > > Callgrind collects data for each execution context. If this always would > include the full call chain, for a lot of programs, you would get a > out-of-memory situation (e.g. firefox). > > Therefore, the default behavior is to only look at the current function > for determination of the context. You can change this: > > * use e.g. "--separate-callers=5" to always use the last 5 entries in > the call stack for the execution context. > * use "--separate-callers5=foo" to specify for function "foo", how much > call stack entries should be used for distinguish the execution > context when running "foo" > * use "--fn-skip=foo" to not change the execution context when calling > into or leaving function foo > > Josef > > > > > > my .gdbinit file: > > > > set env VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind > > file ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux > > handle SIGILL SIGSEGV nostop noprint > > b sim.c:1667 > > run --cache-sim=yes ./toy_prg > > > > Is there something possibly wrong with my setup or is this is a bug in > > Callgrind? Is anyone else seeing things differently. > > > > Siddharth Nilakantan > > > > > > > ------------------------------------------------------------------------------ > > RSA(R) Conference 2012 > > Mar 27 - Feb 2 > > Save $400 by Jan. 27 > > Register now! > > http://p.sf.net/sfu/rsa-sfdev2dev2 > > > > > > > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Siddharth N. <si...@gm...> - 2012-02-06 18:13:56
|
Hi Josef,
I have another question in extension to my previous one. I inserted a
breakpoint in the function I added (see the thread). It breaks whenever
there is a memory read/write. Is the
"CLG_(current_state).bbcc->bb->jmpkind" an accurate reflection of how we
got the the current BB from the previous BB? If so, the function context
should reflect this in case of calls/returns. However, I am seeing the
following:
(gdb) print *vgCallgrind_current_state->cxt->fn[2]
$1 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*, last_cxt =
0x40228edb0, pure_cxt = 0x40228edb0, file = 0x40228e9d0,
next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
is_free = 0 '\000', group = 0, separate_callers = 100,
separate_recursions = 2, verbosity = -1}
(gdb) print *vgCallgrind_current_state->cxt->fn[1]
$2 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt = 0x402291970,
pure_cxt = 0x4022915b0, file = 0x40228e9d0,
next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
is_free = 0 '\000', group = 0, separate_callers = 100,
separate_recursions = 2, verbosity = -1}
(gdb)print *vgCallgrind_current_state->cxt->fn[0]
$3 = {*name = 0x4022971c0 "_dl_setup_hash", number = 3*, last_cxt =
0x402297550, pure_cxt = 0x4022971f0, file = 0x40228e9d0,
next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
is_free = 0 '\000', group = 0, separate_callers = 100,
separate_recursions = 2, verbosity = -1}
(gdb) c
Continuing.
Breakpoint 1, storeDRWcontext (inode=0x40229a128, datasize=4, ea=51840541,
WR=20 '\024') at sim.c:1818
(gdb) print *vgCallgrind_current_state->cxt->fn[2]
Cannot access memory at address 0x0
(gdb) print *vgCallgrind_current_state->cxt->fn[1]
$5 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*, last_cxt =
0x40228edb0, pure_cxt = 0x40228edb0, file = 0x40228e9d0,
next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
is_free = 0 '\000', group = 0, separate_callers = 100,
separate_recursions = 2, verbosity = -1}
(gdb) print *vgCallgrind_current_state->cxt->fn[0]
$6 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt = 0x402291970,
pure_cxt = 0x4022915b0, file = 0x40228e9d0,
next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
is_free = 0 '\000', group = 0, separate_callers = 100,
separate_recursions = 2, verbosity = -1}
(gdb) print vgCallgrind_current_state->bbcc->bb->jmpkind
$8 = 90113* --------------------------> means that we got to this BB
through a call. So how is the function context different?*
Sid
>
>
> On 16 January 2012 22:01, Josef Weidendorfer <Jos...@gm...>wrote:
>
>> Hi,
>>
>> On 16.01.2012 15:31, Siddharth Nilakantan wrote:
>> > Hi All,
>> >
>> > I have written a small extension to callgrind to do some tracking of
>> > memory addresses accessed in functions. My function simply looks at the
>> > current state and determines in which function execution is currently
>> > happening. Then it builds and maintains its own data structures. This
>> > has worked fine so far.
>>
>> Cool.
>>
>> > I want to take this further and also look at the execution context that
>> > Callgrind provides for the current BB being instrumented. However, from
>> > examination using gdb, I noticed that whatever program I run under
>> > Callgrind, the CLG_(current_state)->cxt->size is always 1 and
>> > CLG_(current_state)->cxt->fn[0] is the only valid entry. fn[1], fn[2]
>> > etc. never exist.
>>
>> Callgrind collects data for each execution context. If this always would
>> include the full call chain, for a lot of programs, you would get a
>> out-of-memory situation (e.g. firefox).
>>
>> Therefore, the default behavior is to only look at the current function
>> for determination of the context. You can change this:
>>
>> * use e.g. "--separate-callers=5" to always use the last 5 entries in
>> the call stack for the execution context.
>> * use "--separate-callers5=foo" to specify for function "foo", how much
>> call stack entries should be used for distinguish the execution
>> context when running "foo"
>> * use "--fn-skip=foo" to not change the execution context when calling
>> into or leaving function foo
>>
>> Josef
>>
>>
>> >
>> > my .gdbinit file:
>> >
>> > set env VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind
>> > file ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux
>> > handle SIGILL SIGSEGV nostop noprint
>> > b sim.c:1667
>> > run --cache-sim=yes ./toy_prg
>> >
>> > Is there something possibly wrong with my setup or is this is a bug in
>> > Callgrind? Is anyone else seeing things differently.
>> >
>> > Siddharth Nilakantan
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Mar 27 - Feb 2
>> > Save $400 by Jan. 27
>> > Register now!
>> > http://p.sf.net/sfu/rsa-sfdev2dev2
>> >
>> >
>> >
>> > _______________________________________________
>> > Valgrind-developers mailing list
>> > Val...@li...
>> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>
>
|
|
From: Siddharth N. <si...@gm...> - 2012-03-02 17:41:06
|
Hi Josef,
Any word on this? How do we find out how we got to the current BB from the
previous BB? I can't seem to find any clear indications in the code or the
documentation for this. Any help on this matter would be sincerely
appreciated.
Thanks,
Sid
On 6 February 2012 13:13, Siddharth Nilakantan <si...@gm...> wrote:
> Hi Josef,
>
> I have another question in extension to my previous one. I inserted a
> breakpoint in the function I added (see the thread). It breaks whenever
> there is a memory read/write. Is the
> "CLG_(current_state).bbcc->bb->jmpkind" an accurate reflection of how we
> got the the current BB from the previous BB? If so, the function context
> should reflect this in case of calls/returns. However, I am seeing the
> following:
>
> (gdb) print *vgCallgrind_current_state->cxt->fn[2]
> $1 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*, last_cxt =
> 0x40228edb0, pure_cxt = 0x40228edb0, file = 0x40228e9d0,
> next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
> 0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
> pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
> is_free = 0 '\000', group = 0, separate_callers = 100,
> separate_recursions = 2, verbosity = -1}
>
> (gdb) print *vgCallgrind_current_state->cxt->fn[1]
> $2 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt =
> 0x402291970, pure_cxt = 0x4022915b0, file = 0x40228e9d0,
> next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
> 0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
> pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
> is_free = 0 '\000', group = 0, separate_callers = 100,
> separate_recursions = 2, verbosity = -1}
>
> (gdb)print *vgCallgrind_current_state->cxt->fn[0]
> $3 = {*name = 0x4022971c0 "_dl_setup_hash", number = 3*, last_cxt =
> 0x402297550, pure_cxt = 0x4022971f0, file = 0x40228e9d0,
> next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
> 0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
> pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
> is_free = 0 '\000', group = 0, separate_callers = 100,
> separate_recursions = 2, verbosity = -1}
>
> (gdb) c
> Continuing.
>
> Breakpoint 1, storeDRWcontext (inode=0x40229a128, datasize=4, ea=51840541,
> WR=20 '\024') at sim.c:1818
> (gdb) print *vgCallgrind_current_state->cxt->fn[2]
> Cannot access memory at address 0x0
>
> (gdb) print *vgCallgrind_current_state->cxt->fn[1]
> $5 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*, last_cxt =
> 0x40228edb0, pure_cxt = 0x40228edb0, file = 0x40228e9d0,
> next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
> 0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
> pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
> is_free = 0 '\000', group = 0, separate_callers = 100,
> separate_recursions = 2, verbosity = -1}
>
> (gdb) print *vgCallgrind_current_state->cxt->fn[0]
> $6 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt =
> 0x402291970, pure_cxt = 0x4022915b0, file = 0x40228e9d0,
> next = 0x0, dump_before = 0 '\000', dump_after = 0 '\000', zero_before =
> 0 '\000', toggle_collect = 0 '\000', skip = 0 '\000',
> pop_on_jump = 0 '\000', is_malloc = 0 '\000', is_realloc = 0 '\000',
> is_free = 0 '\000', group = 0, separate_callers = 100,
> separate_recursions = 2, verbosity = -1}
>
> (gdb) print vgCallgrind_current_state->bbcc->bb->jmpkind
> $8 = 90113* --------------------------> means that we got to this BB
> through a call. So how is the function context different?*
>
> Sid
>
>
>>
>> On 16 January 2012 22:01, Josef Weidendorfer <Jos...@gm...>wrote:
>>
>>> Hi,
>>>
>>> On 16.01.2012 15:31, Siddharth Nilakantan wrote:
>>> > Hi All,
>>> >
>>> > I have written a small extension to callgrind to do some tracking of
>>> > memory addresses accessed in functions. My function simply looks at the
>>> > current state and determines in which function execution is currently
>>> > happening. Then it builds and maintains its own data structures. This
>>> > has worked fine so far.
>>>
>>> Cool.
>>>
>>> > I want to take this further and also look at the execution context that
>>> > Callgrind provides for the current BB being instrumented. However, from
>>> > examination using gdb, I noticed that whatever program I run under
>>> > Callgrind, the CLG_(current_state)->cxt->size is always 1 and
>>> > CLG_(current_state)->cxt->fn[0] is the only valid entry. fn[1], fn[2]
>>> > etc. never exist.
>>>
>>> Callgrind collects data for each execution context. If this always would
>>> include the full call chain, for a lot of programs, you would get a
>>> out-of-memory situation (e.g. firefox).
>>>
>>> Therefore, the default behavior is to only look at the current function
>>> for determination of the context. You can change this:
>>>
>>> * use e.g. "--separate-callers=5" to always use the last 5 entries in
>>> the call stack for the execution context.
>>> * use "--separate-callers5=foo" to specify for function "foo", how much
>>> call stack entries should be used for distinguish the execution
>>> context when running "foo"
>>> * use "--fn-skip=foo" to not change the execution context when calling
>>> into or leaving function foo
>>>
>>> Josef
>>>
>>>
>>> >
>>> > my .gdbinit file:
>>> >
>>> > set env VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind
>>> > file ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux
>>> > handle SIGILL SIGSEGV nostop noprint
>>> > b sim.c:1667
>>> > run --cache-sim=yes ./toy_prg
>>> >
>>> > Is there something possibly wrong with my setup or is this is a bug in
>>> > Callgrind? Is anyone else seeing things differently.
>>> >
>>> > Siddharth Nilakantan
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > RSA(R) Conference 2012
>>> > Mar 27 - Feb 2
>>> > Save $400 by Jan. 27
>>> > Register now!
>>> > http://p.sf.net/sfu/rsa-sfdev2dev2
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Valgrind-developers mailing list
>>> > Val...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Mar 27 - Feb 2
>>> Save $400 by Jan. 27
>>> Register now!
>>> http://p.sf.net/sfu/rsa-sfdev2dev2
>>> _______________________________________________
>>> Valgrind-developers mailing list
>>> Val...@li...
>>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>>
>>
>>
>
|
|
From: Siddharth N. <si...@gm...> - 2012-03-06 20:56:44
|
Hi Josef,
I quickly migrated my code to valgrind 3.7. I noticed that
CLG_(current_state)->bbcc->bb actually points to the BB that is executing
currently. You mentioned that "The jumpkind is
now stored for every side exit, and for the last, you have to look at
"...bb->jmp[...bb->cjmp_count-1].jmpkind" ".
I followed these steps:
1. created BB* variable *bb_temp* in *current_state*
2. While using gdb, I can break during a particular BB (say, BB1) and get
the value of the pointer to it.* (gdb) set variable current_state.bb_temp =
<that value>*
3. After this, at the next breakpoint where I see a context change (so a
new BB, but not necessarily the immediately next one, until I confirm with
ct-verbose=2 ), I can observe
*current_state->bb_temp->jmp[current_state->bb_temp->cjmp_count
- 1]* and that should tell me how BB1 exited, correct?
However, for what should be a call or a return, I see that the cjmp_count =
0 even after that BB has been exited. I have not yet tried ct-verbose=2 to
see the x86 assembly. I will try that next.
Sid
On 2 March 2012 16:38, Josef Weidendorfer <Jos...@gm...> wrote:
> On 02.03.2012 18:40, Siddharth Nilakantan wrote:
>>
>> Hi Josef,
>>
>> Any word on this?
>
>
> I saw your mail, but forgot to answer...
>
>
> How do we find out how we got to the current BB from
>>
>> the previous BB? I can't seem to find any clear indications in the code
>> or the documentation for this. Any help on this matter would be
>> sincerely appreciated.
>>
>> Thanks,
>> Sid
>>
>> On 6 February 2012 13:13, Siddharth Nilakantan <si...@gm...
>> <mailto:si...@gm...>> wrote:
>>
>> Hi Josef,
>>
>> I have another question in extension to my previous one. I inserted
>> a breakpoint in the function I added (see the thread). It breaks
>> whenever there is a memory read/write. Is the
>> "CLG_(current_state).bbcc->bb->jmpkind" an accurate reflection of
>> how we got the the current BB from the previous BB?
>
>
> All information in a BB struct is collected when instrumenting a given
> BB. bb->jmpkind is the kind of jump got from VEX for the end of the BB.
> This is taken as hint, but is modified by some heuristics in setup_bbcc
> (look at what happens to the local "jmpkind" variable in setup_bbcc).
>
> At the moment, you can not get an "accurate reflection of how we got
> to the current BB from the previous BB" outside of setup_bbcc.
> If you need that, you could add such a field to CLG_(current_state),
> and store the local jmpkind into that field at the end of setup_bbcc.
>
>
>> If so, the
>> function context should reflect this in case of calls/returns.
>> However, I am seeing the following:
>>
>> (gdb) print *vgCallgrind_current_state->cxt->fn[2]
>> $1 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*,
>
>
>> (gdb) print *vgCallgrind_current_state->cxt->fn[1]
>> $2 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt =
>
>
>> (gdb)print *vgCallgrind_current_state->cxt->fn[0]
>> $3 = {*name = 0x4022971c0 "_dl_setup_hash", number = 3*, last_cxt =
>
>
> Ok, so here the context is
>
> _dl_setup_hash called from _dl_start called from 0x0000003170400a70
>
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 1, storeDRWcontext (inode=0x40229a128, datasize=4,
>> ea=51840541, WR=20 '\024') at sim.c:1818
>> (gdb) print *vgCallgrind_current_state->cxt->fn[2]
>> Cannot access memory at address 0x0
>>
>> (gdb) print *vgCallgrind_current_state->cxt->fn[1]
>> $5 = {*name = 0x40228ed70 "0x0000003170400a70", number = 1*,
>>
>>
>> (gdb) print *vgCallgrind_current_state->cxt->fn[0]
>> $6 = {*name = 0x402291580 "_dl_start", number = 2*, last_cxt =
>
>
> And here, it is
>
> _dl_start called from 0x0000003170400a70
>
> There must have been a return from _dl_setup_hash.
> Are you sure about your breakpoint stopping in the next BB?
> To check, you can ask Callgrind for debut output with "--ct-verbose=2".
>
>> (gdb) print vgCallgrind_current_state->bbcc->bb->jmpkind
>> $8 = 90113*--------------------------> means that we got to this BB
>> through a call. So how is the function context different?*
>
>
> Indeed, 90113 is 0x16001 which is Ijk_Call, according to libvex_ir.h.
>
> So either the VEX call was converted to a return, or the return was
> done by a side exit, and not at the end of the BB (which bb->jmpkind is
> about).
>
> The only way where a VEX call is changed to a return is when
> synchronizing Callgrinds' shadow stack with the real one (by help
> of the stack pointer SP) will need a element to be pop'ed from the
> shadow stack.
> I have no idea why this triggers for you here.
>
> Really, to see what is going on, use --ct-verbose=2, or in addition
> "--trace-flags=10000000 --trace-notbelow=0", to see the x86 code
> seen by valgrind.
>
>
> Josef
>
>
> PS: in SVN trunk, there is no bb->jmpkind any more. The jumpkind is
> now stored for every side exit, and for the last, you have to look at
> "...bb->jmp[...bb->cjmp_count-1].jmpkind"
>
>
>>
>> Sid
>>
>>
>>
>> On 16 January 2012 22:01, Josef Weidendorfer
>> <Jos...@gm... <mailto:Jos...@gm...>>
>>
>> wrote:
>>
>> Hi,
>>
>> On 16.01.2012 15:31, Siddharth Nilakantan wrote:
>> > Hi All,
>> >
>> > I have written a small extension to callgrind to do some
>> tracking of
>> > memory addresses accessed in functions. My function
>> simply looks at the
>> > current state and determines in which function execution
>> is currently
>> > happening. Then it builds and maintains its own data
>> structures. This
>> > has worked fine so far.
>>
>> Cool.
>>
>> > I want to take this further and also look at the
>> execution context that
>> > Callgrind provides for the current BB being instrumented.
>> However, from
>> > examination using gdb, I noticed that whatever program I
>> run under
>> > Callgrind, the CLG_(current_state)->cxt->size is always 1
>> and
>> > CLG_(current_state)->cxt->fn[0] is the only valid entry.
>> fn[1], fn[2]
>> > etc. never exist.
>>
>> Callgrind collects data for each execution context. If this
>> always would
>> include the full call chain, for a lot of programs, you
>> would get a
>> out-of-memory situation (e.g. firefox).
>>
>> Therefore, the default behavior is to only look at the
>> current function
>> for determination of the context. You can change this:
>>
>> * use e.g. "--separate-callers=5" to always use the last 5
>> entries in
>> the call stack for the execution context.
>> * use "--separate-callers5=foo" to specify for function
>> "foo", how much
>> call stack entries should be used for distinguish the
>> execution
>> context when running "foo"
>> * use "--fn-skip=foo" to not change the execution context
>> when calling
>> into or leaving function foo
>>
>> Josef
>>
>>
>> >
>> > my .gdbinit file:
>> >
>> > set env
>> VALGRIND_LAUNCHER=~/valgrind-svnco/valgrind/coregrind/valgrind
>> > file
>> ~/valgrind-svnco/valgrind/.in_place/callgrind-amd64-linux
>> > handle SIGILL SIGSEGV nostop noprint
>> > b sim.c:1667
>> > run --cache-sim=yes ./toy_prg
>> >
>> > Is there something possibly wrong with my setup or is
>> this is a bug in
>> > Callgrind? Is anyone else seeing things differently.
>> >
>> > Siddharth Nilakantan
>> >
>> >
>> >
>>
>>
------------------------------------------------------------------------------
>> > RSA(R) Conference 2012
>> > Mar 27 - Feb 2
>> > Save $400 by Jan. 27
>> > Register now!
>> > http://p.sf.net/sfu/rsa-sfdev2dev2
>> >
>> >
>> >
>> > _______________________________________________
>> > Valgrind-developers mailing list
>> > Val...@li...
>> <mailto:Val...@li...>
>>
>> >
>>
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>>
>>
>>
------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> <mailto:Val...@li...>
>>
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>>
>>
>>
>>
>>
>>
>>
------------------------------------------------------------------------------
>> Virtualization& Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>
>>
>>
>>
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
>
|
|
From: Siddharth N. <si...@gm...> - 2012-03-06 22:02:02
|
Ohh, so by last, you meant the final exit (non-side exit) is the value of cjmp_count. So there really is no way of determining how we got to the current BB from the previous one, as it could have used any of the exits in the jmp[] array. Is there any point in the code where I can capture and store the index of the most recently used exit for a BB or is setup_bbcc's jmpkind the closest I can get to that? On 6 March 2012 16:26, Josef Weidendorfer <Jos...@gm...> wrote: > On 06.03.2012 21:56, Siddharth Nilakantan wrote: > > However, for what should be a call or a return, I see that the > > cjmp_count = 0 even after that BB has been exited. > > Ah, sorry, I was to fast. "cjmp_count" is the number of side > exits, which of course can be 0. The length of the BB::jmp[] > array is cjmp_count+1. Thus, > > > I quickly migrated my code to valgrind 3.7. I noticed that >> CLG_(current_state)->bbcc->bb actually points to the BB that is >> executing currently. You mentioned that "The jumpkind is >> now stored for every side exit, and for the last, you have to look at >> "...bb->jmp[...bb->cjmp_count-**1].jmpkind" ". >> > > This must be "...bb->jmp[...bb->cjmp_count]**.jmpkind" instead. > > Josef > |
|
From: Siddharth N. <si...@gm...> - 2012-03-06 23:29:18
|
haha, I knew there must be a way. great! So I'm guessing jmpkind at the end of setup_bbcc() for BB1 should be the same as CLG_(current_state)->jmp[CLG_(current_state).jmps_passed].jmpkind when setup_bbcc() is called for the next immediate BB. Thanks a lot for your help. I'll use this info and let you know what happens. On 6 March 2012 17:37, Josef Weidendorfer <Jos...@gm...> wrote: > On 06.03.2012 23:01, Siddharth Nilakantan wrote: > >> Ohh, so by last, you meant the final exit (non-side exit) is the value >> of cjmp_count. So there really is no way of determining >> > > There is a way ;-) > > > how we got to > >> the current BB from the previous one, as it could have used any of the >> exits in the jmp[] array. >> > > That is correct. However, setup_bbcc() knows the side exit from last BB: > Callgrind instruments a write to "CLG_(current_state).jmps_**passed" > before every side exit. Thus, when setup_bbcc() is called at the > beginning of the next BB, "CLG_(current_state).jmps_**passed" will > contain the side exit number. > > But you should not use "CLG_(current_state).jmps_**passed" outside of > setup_bbcc() yourself, as it is reused to find out the side exit number > of the currently running BB. > > The jmp[] array (and the complete BB struct) only stores information found > at last instrumentation, and thus is static. > > > Is there any point in the code where I can > >> capture and store the index of the most recently used exit for a BB or >> is setup_bbcc's jmpkind the closest I can get to that? >> > > Exactly. As mentioned in my last mail, you can store the "jmpkind" at > the end of setup_bbcc() into a new field of CLG_(current_state). > That alwyas should be correct. > > Probably, this technique to overwrite a global before every side exit > to find out the side exit number seems a little dumb to you. But I do > not see another way, as Valgrind does not allow instrumentation at > side exits. > > Josef > > >> On 6 March 2012 16:26, Josef Weidendorfer <Jos...@gm... >> <mailto:Josef.Weidendorfer@**gmx.de <Jos...@gm...>>> wrote: >> >> On 06.03.2012 21:56, Siddharth Nilakantan wrote: >> > However, for what should be a call or a return, I see that the >> > cjmp_count = 0 even after that BB has been exited. >> >> Ah, sorry, I was to fast. "cjmp_count" is the number of side >> exits, which of course can be 0. The length of the BB::jmp[] >> array is cjmp_count+1. Thus, >> >> >> I quickly migrated my code to valgrind 3.7. I noticed that >> CLG_(current_state)->bbcc->bb actually points to the BB that is >> executing currently. You mentioned that "The jumpkind is >> now stored for every side exit, and for the last, you have to >> look at >> "...bb->jmp[...bb->cjmp_count-**__1].jmpkind" ". >> >> >> This must be "...bb->jmp[...bb->cjmp_count]**__.jmpkind" instead. >> >> Josef >> >> >> > |
|
From: Siddharth N. <si...@gm...> - 2012-03-16 16:09:21
|
I was supposed to reply to this earlier! This method of looking at "CLG_(current_state).jmps_**passed" worked fine, so we can accurately figure out how we got to the current BB from the previous one. On 6 March 2012 18:28, Siddharth Nilakantan <si...@gm...> wrote: > haha, I knew there must be a way. great! So I'm guessing jmpkind at the > end of setup_bbcc() for BB1 should be the same as > CLG_(current_state)->jmp[CLG_(current_state).jmps_passed].jmpkind when > setup_bbcc() is called for the next immediate BB. > > Thanks a lot for your help. I'll use this info and let you know what > happens. > > > On 6 March 2012 17:37, Josef Weidendorfer <Jos...@gm...>wrote: > >> On 06.03.2012 23:01, Siddharth Nilakantan wrote: >> >>> Ohh, so by last, you meant the final exit (non-side exit) is the value >>> of cjmp_count. So there really is no way of determining >>> >> >> There is a way ;-) >> >> >> how we got to >> >>> the current BB from the previous one, as it could have used any of the >>> exits in the jmp[] array. >>> >> >> That is correct. However, setup_bbcc() knows the side exit from last BB: >> Callgrind instruments a write to "CLG_(current_state).jmps_**passed" >> before every side exit. Thus, when setup_bbcc() is called at the >> beginning of the next BB, "CLG_(current_state).jmps_**passed" will >> contain the side exit number. >> >> But you should not use "CLG_(current_state).jmps_**passed" outside of >> setup_bbcc() yourself, as it is reused to find out the side exit number >> of the currently running BB. >> >> The jmp[] array (and the complete BB struct) only stores information >> found at last instrumentation, and thus is static. >> >> >> Is there any point in the code where I can >> >>> capture and store the index of the most recently used exit for a BB or >>> is setup_bbcc's jmpkind the closest I can get to that? >>> >> >> Exactly. As mentioned in my last mail, you can store the "jmpkind" at >> the end of setup_bbcc() into a new field of CLG_(current_state). >> That alwyas should be correct. >> >> Probably, this technique to overwrite a global before every side exit >> to find out the side exit number seems a little dumb to you. But I do >> not see another way, as Valgrind does not allow instrumentation at >> side exits. >> >> Josef >> >> >>> On 6 March 2012 16:26, Josef Weidendorfer <Jos...@gm... >>> <mailto:Josef.Weidendorfer@**gmx.de <Jos...@gm...>>> wrote: >>> >>> On 06.03.2012 21:56, Siddharth Nilakantan wrote: >>> > However, for what should be a call or a return, I see that the >>> > cjmp_count = 0 even after that BB has been exited. >>> >>> Ah, sorry, I was to fast. "cjmp_count" is the number of side >>> exits, which of course can be 0. The length of the BB::jmp[] >>> array is cjmp_count+1. Thus, >>> >>> >>> I quickly migrated my code to valgrind 3.7. I noticed that >>> CLG_(current_state)->bbcc->bb actually points to the BB that is >>> executing currently. You mentioned that "The jumpkind is >>> now stored for every side exit, and for the last, you have to >>> look at >>> "...bb->jmp[...bb->cjmp_count-**__1].jmpkind" ". >>> >>> >>> This must be "...bb->jmp[...bb->cjmp_count]**__.jmpkind" instead. >>> >>> Josef >>> >>> >>> >> > |