|
From: Lu M. <kin...@gm...> - 2013-05-29 19:45:05
|
Hello all, Under Linux, the first instruction executed in executable is in _start function rather than in main function. I am wondering whether Valgrind instrument the load/store in any other functions except main function and its subroutine (ex. _start function). According to Valgrind paper, all memory is marked as unaddressable except malloced. If Valgrind instrument memory check with load/store in _start function. It may report a false-positive error. How does Valgrind deal with this problem? Thanks a lot. |
|
From: Niall D. <ndo...@bl...> - 2013-05-29 20:04:35
Attachments:
smime.p7s
|
> Under Linux, the first instruction executed in executable is in _start function > rather than in main function. I am wondering whether Valgrind instrument the > load/store in any other functions except main function and its subroutine (ex. > _start function). According to Valgrind paper, all memory is marked as > unaddressable except malloced. If Valgrind instrument memory check with > load/store in _start function. It may report a false-positive error. How does > Valgrind deal with this problem? I think you may misunderstand what valgrind is. Valgrind emulates a CPU. It therefore can, and does, track all reads and writes of memory across the process irrespective of what the code is. Valgrind has no concept of main being different to _start, or indeed of main, it just calls what ELF tells it to. If there are any false positives, it's either a bug in valgrind (very rare) or your code is doing something very unusual and probably should be doing it differently. The only legitimate source of false positives in memcheck I'm aware of is the magic cookie technique where one speculatively reads unknown memory locations for the presence of a magic cookie. In this situation you should not suppress the error, but you should instrument the code using valgrind's macro support to tell valgrind what you're really doing. Niall |
|
From: John R. <jr...@bi...> - 2013-05-29 20:31:10
|
> Under Linux, the first instruction executed in executable is in _start function rather than in main function. In most processes the first instruction executed after execve() is from the Elf64_Ehdr.e_entry of the PT_LOAD such as ld-linux.so.2. This instruction is not "in [the] executable file" that was named as the first argument to execve(), but it is "in the address space of the process". Yes, memcheck does instrument it. -- |
|
From: Lu M. <kin...@gm...> - 2013-05-30 17:07:04
|
Hello,
I realized that Valgrind instrument all read/write instruction in user
address space now. But 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.w fp, #0
8344: f04f 0e00 mov.w lr, #0
8348: f85d 1b04 ldr.w r1, [sp], #4
834c: 466a mov r2, sp
834e: f84d 2d04 str.w r2, [sp, #-4]!
8352: f84d 0d04 str.w r0, [sp, #-4]!
8356: f8df c014 ldr.w ip, [pc, #20] ; 836c <_start+0x2c>
835a: f84d cd04 str.w ip, [sp, #-4]!
835e: 4804 ldr r0, [pc, #16] ; (8370 <_start+0x30>)
8360: 4b04 ldr r3, [pc, #16] ; (8374 <_start+0x34>)
8362: f7ff efda blx 8318 <_init+0x38>
8366: f7ff efe6 blx 8334 <_init+0x54>
836a: 0000 .short 0x0000
836c: 00008441 .word 0x00008441
8370: 000083b9 .word 0x000083b9
8374: 000083fd .word 0x000083fd
...
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? If I want to understand what Valgrind initialize the shadow,
which files should I take a look?
Thank you very much.
2013/5/30 Lu Mitnick <kin...@gm...>
> Hello all,
>
> Under Linux, the first instruction executed in executable is in _start
> function rather than in main function. I am wondering whether Valgrind
> instrument the load/store in any other functions except main function and
> its subroutine (ex. _start function). According to Valgrind paper, all
> memory is marked as unaddressable except malloced. If Valgrind instrument
> memory check with load/store in _start function. It may report a
> false-positive error. How does Valgrind deal with this problem?
>
> Thanks a lot.
>
>
|
|
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.] -- |