On Wednesday 24 August 2011, Emilio Coppa wrote:
> > . > strlen(0x40183b6, 0xbe918faa, ...) [ld-2.13.so / 0x16c20]
> > . > calloc(0x2e9, 0x1, ...) [ld-2.13.so / 0x14dd0]
> > . > 0x000174ab(0xbe918194, 0x401cff4, ...) [ld-2.13.so / 0x174ab]
> > . .> malloc(0x2e9, 0x401cff4, ...) [ld-2.13.so / 0x14da0]
> > . . > 0x000174ab(0x401cff4, 0xbe918158, ...) [ld-2.13.so / 0x174ab]
> > . . > __libc_memalign(0x8, 0x2e9, ...) [ld-2.13.so / 0x14c90]
> > . . > 0x000174ab(0x0, 0x0, ...) [ld-2.13.so / 0x174ab]
> > . > memcpy(0x401dc00, 0x40183b6, ...) [ld-2.13.so / 0x17330]
Hmm... strlen shouldn't need to call calloc, so your output seems to be sane.
What distribution is this?
Can you locate the relevant output of "valgrind --tool=callgrind --ct-verbose=2
..."?
And can you show the relevant disassembly of ld-2.13.so at offset 0x16c20 ?
The calls to 0x000174ab should be fine. They most probably are about getting the
GOT pointer for the library.
> My code says (number inside [] is my simulated stack depth ):
>
>
> > [5] Entered strlen()
> > [5] Exit strlen()
> > [4] Inside _dl_new_object
> > Valgrind does not know where we are: 0x40007E4
When do you print out this?
> > [5] Entered calloc()
> > Valgrind does not know where we are: 0x40174AB
> > Valgrind does not know where we are: 0x40007D4
> > [6] Entered malloc()
> > Valgrind does not know where we are: 0x40174AB
> > Valgrind does not know where we are: 0x40007C4
> > [7] Entered __libc_memalign()
> > Valgrind does not know where we are: 0x40174AB
> > [7] Exit __libc_memalign()
> > [6] Inside malloc
> > [6] Exit malloc()
> > [5] Inside calloc
> > [5] Exit calloc()
> > [4] Inside _dl_new_object
> > [5] Entered memcpy()
> > [5] Exit memcpy()
>
>
> As you can see with my code strlen() return immediately, with callgrind
> not.
> There are a lot of other difference if you see the two files.
>
> Callgrind not only assumes a call if VG_(get_fnname_if_entry) is true, but
> > also,
> > if VEX returns jump kind "Call" for the last BB.
>
>
> Why this? I mean if the last BB do a jump type Ijk_Call, why does it not
> jump to first instruction of a BB (of another function)?
Of course it does. But it could be that there is not debug info available,
and thus, Valgrind can not tell whether this is the beginning of a function
or not.
> I expect this if
> it's a "call". Sorry if it's a stupid question.
>
> Can I do this: during instrumentation, if jmpkind of the BB is Ijk_Call
> invoke an helper function that simulate the call ?
I think that should work, yes.
> - tail recursions (jumping to the beginning of a function)
> >
>
> Ok, I am seeing your code ( setup_bbcc() ), you do a lot of things:
>
> - if last BB has a jmpkind == IjkRet and SP is smaller or equal (if is a
> return we expect a bigger SP) to the one on top of the stack, you
> set ret_without_call = True
I do not remember any more, but I suppose I added this when I found
a case with "PUSH addr; RET" or similar.
> - you simulate a call if:
>
> ret_without_call is true OR
>
> current BB is the first BB of a function OR
> (last_bb->sect_kind != bb->sect_kind) || (last_bb->obj->number !=
> bb->obj->number)
>
>
> Am I correct?
Yes, if it is not a return.
The result is that sometimes jumps (e.g. among libraries) will be
converted into calls.
This really is spaghetti code. It should be rewritten more clearly.
> > - signal handlers (you will see arbitrary function calls when a signal
> > handler
> > calls a function)
> >
>
> How callgrind manage this?
Valgrind core can catch enter/leave of signal handlers. I put a marker
into the shadow stack if I see a signal handler being called. This way,
even long jumps out of signal handlers are detectede. Valgrind can not
catch such returns from signal handlers, which are invisible to the kernel.
Josef
> > However, this does not work nicely with RISC architectures (PPC/ARM), as a
> > call or
> > a return does not need to change the SP there. Instead, the return address
> > is stored
> > and restored from a specific register ("link register") using regular
> > branch instructions.
> > Callgrind does not do this right at the moment, too.
>
>
> Ok.
>
> Emilio.
>
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
