|
From: Yue C. <yc...@gm...> - 2015-09-16 03:23:44
|
Under x86_64 Linux, I change
VG_(printf)("I %08lx,%lu\n", addr, size);
to
VG_(printf)("I %16lx,%lu\n", addr, size);
in lackey, but the result seems not correct too.
The output is something like
I 4ca3292,2
But the real code address is around 400xxx (6 digits, not 7), which
differs from
the lackey output.
On Tue, Sep 15, 2015 at 4:25 PM, Philippe Waroquiers <
phi...@sk...> wrote:
> On Tue, 2015-09-15 at 04:19 -0400, Yue Chen wrote:
> > Hi,
> >
> >
> > Due to instrumentation, when doing memory tracing using tool lackey
> > (``--tool=lackey --trace-mem=yes''), the recorded instruction
> > addresses seem different from the original program's (e.g., ``I
> > 04002166, 2''), and only have a 32-bit format output.
> >
> >
> > Is there any way that I can translate this address to the original
> > one?
> >
> >
> > My environment is x86-64 FreeBSD 10.1.
> FreeBSD port is not part of the valgrind (IMO, would be good
> to merge the port).
>
> Apart of that, checking on a 32 bits and 64 bits linux, lackey properly
> shows the address of the instructions being executed.
>
> This is the way I tested:
> gdb ./memcheck/tests/trivialleak
> (gdb) disass main
> //// select one or 2 relevant instructions
>
> Then run lackey, and see that these instructions were properly
> reported, with their length.
> The fact that they look only 32 bits (even on a 64 bits) is that lackey
> is printing the addresses with code such as:
> VG_(printf)("I %08lx,%lu\n", addr, size);
> but that will properly print the correct values if addresses are > 4GB.
>
> So, if really the addresses reported by lackey do not match your
> executable, maybe there is something strange on FreeBSD port ?
>
> Philippe
>
>
>
>
|