|
From: John R. <jr...@bi...> - 2013-06-01 21:18:28
|
> I have no idea about the initial status of shadow memory. > > Take a simple arm executable as an example: > $ arm-linux-gnueabi-objdump -S MallocNor-RW > ... > Disassembly of section .text: > > 00008340 <_start>: > 8340:f04f 0b00 mov.wfp, #0 > 8344:f04f 0e00 mov.wlr, #0 > 8348:f85d 1b04 ldr.wr1, [sp], #4 > ... > > In 8348, CPU load [sp] into r1 and increment sp by 4. > Which status should the shadow value of [sp] and r1 be? defined, uninitialized or unaddressable? Remember that valgrind is a co-resident emulator which lives in the same process and address space while valgrind loads and "invokes" your program. The Linux kernel invokes valgrind via execve() from your shell, and the Linux kernel is "unaware" that valgrind is an emulator. Because valgrind does the loading of your program, then valgrind already knows the layout that the emulated program has. Valgrind also sets the register contents that are seen by the emulated program, so valgrind also knows about that, too. The only "magic" involved is trimming the valgrind arguments from the leading positions of valgrind's own argv[], plus some minor editing of environ[] and some other small pieces of valgrind's original stack. > If I want to understand what Valgrind initialize the shadow, which files should I take a look? coregrind/m_aspacemgr/ and the callers from memcheck/ coregrind/pub_core_aspacemgr.h coregrind/m_initimg/initimg-linux.c [It should not have been difficult to answer that question yourself.] -- |