|
From: Mikael J. <ma...@mi...> - 2012-07-23 09:38:07
|
Hi, I'm trying to figure out when memory allocated on the heap by the client program is touched, but the addresses given by L/S lines are in an entirely different address space: Client: Allocated memory at 0x41C7028 S at 0x384D3024 .... How do I convert them into the same address space as my client application uses? Thanks in advance, -- Mikael Jansson http://mikael.jansson.be |
|
From: janjust <tja...@un...> - 2012-07-23 13:48:40
|
Hi, Out of curiosity is the allocated address from a run without Valgrind vs. the store at address run with Valgrind? Tommy Mikael Jansson-2 wrote: > > Hi, > > I'm trying to figure out when memory allocated on the heap by the > client program is touched, but the addresses given by L/S lines are in > an entirely different address space: > > Client: Allocated memory at 0x41C7028 > S at 0x384D3024 > .... > > How do I convert them into the same address space as my client application > uses? > > Thanks in advance, > -- > Mikael Jansson > http://mikael.jansson.be > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://old.nabble.com/Real-%28client%29-addresses-from-Lackey%27s-mem-trace-option--tp34199075p34200101.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Mikael J. <ma...@mi...> - 2012-07-23 17:32:55
|
Hi Tommy,
>
> Out of curiosity is the allocated address from a run without Valgrind vs.
> the store at address run with Valgrind?
This is all from a single run. And I notice now that I wrote Lackey,
where it's actually memcheck I've modified.
$ valgrind --tool=memcheck --mem-trace=yes ./test
where test.c, compiled by gcc with -O0:
int main() {
char *p = (char *)malloc(10);
*p='A';
}
In mc_malloc_wrappers.c, around line 290 at the end of MC_(new_block):
+ VG_(printf)("-> new block %p\n", p);
In mc_translate.c, in MC_(instrument), in the case Ist_Store:
+ VG_(printf)("S %p\n", ist->Store.addr)
The first addition shows the address of the memory allocated by the
client program (through the malloc wrapper in memcheck), and the other
addition is to show the address of the store statement being
instrumented.
Have I misunderstood how ist->Store.addr is supposed to be used, or
should I look for the address elsewhere? Optionally, can I get another
representation of the allocated memory chunk?
Thanks in advance,
- Mikael
> Tommy
>
>
> Mikael Jansson-2 wrote:
>>
>> Hi,
>>
>> I'm trying to figure out when memory allocated on the heap by the
>> client program is touched, but the addresses given by L/S lines are in
>> an entirely different address space:
>>
>> Client: Allocated memory at 0x41C7028
>> S at 0x384D3024
>> ....
>>
>> How do I convert them into the same address space as my client application
>> uses?
>>
>> Thanks in advance,
>> --
>> Mikael Jansson
>> http://mikael.jansson.be
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Real-%28client%29-addresses-from-Lackey%27s-mem-trace-option--tp34199075p34200101.html
> Sent from the Valgrind - Users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Mikael Jansson
http://mikael.jansson.be
|
|
From: Josef W. <Jos...@gm...> - 2012-07-23 18:00:54
|
Am 23.07.2012 19:08, schrieb Mikael Jansson:
> + VG_(printf)("S %p\n", ist->Store.addr)
> ...
> Have I misunderstood how ist->Store.addr is supposed to be used,
Yes. IRStmt.Store.addr is of type IRExpr*. You are printing out
the address of a structure used for the VEX IR while instrumentation
of a code block is done. The code behind never was executed yet!
To get to the real address, you have to catch it while code is
executed, e.g. by instrumenting a call to your own function when
a store is done. See lackey for how to do that.
Josef
|
|
From: Mikael J. <ma...@mi...> - 2012-07-23 22:17:40
|
On Mon, Jul 23, 2012 at 8:00 PM, Josef Weidendorfer
<Jos...@gm...> wrote:
> Am 23.07.2012 19:08, schrieb Mikael Jansson:
>> + VG_(printf)("S %p\n", ist->Store.addr)
>> ...
>> Have I misunderstood how ist->Store.addr is supposed to be used,
>
> Yes. IRStmt.Store.addr is of type IRExpr*. You are printing out
> the address of a structure used for the VEX IR while instrumentation
> of a code block is done. The code behind never was executed yet!
Ah, thanks!
> To get to the real address, you have to catch it while code is
> executed, e.g. by instrumenting a call to your own function when
> a store is done. See lackey for how to do that.
Would that be the trace_...() instructions in Lackey? Because, output
from --tool=lackey --trace-mem=yes looks like this:
I 040fc67c,7
L 041b88e0,4
S be95f5d0,4
I 040010c0,2
AFTER strdup, memory at 0x804B008 has contents h
I 040010c2,1
L be95f5d0,4
I 040fc683,1
The line in the middle is output by my client program, that does a
strdup("hello") and prints the address. strdup() should use some sort
malloc() underneath, right? However, searching for the address I got,
0x804B..., yields no results in the entire instrumentation log.
Or did I misunderstand you, and the addresses printed out by
trace_load() / trace_store() / trace_instr() are still just IRExpr
pointers?
Thanks,
Mikael
--
Mikael Jansson
http://mikael.jansson.be
|