|
From: vijay n. <vi...@gm...> - 2012-09-28 12:09:38
|
Hi Julian,
Valgrind's VDSO collides with my executables load section. Is it possible
to relocate load VDSO ?
Below are my executables phdr details.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00048034 0x00048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x00048114 0x00048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
* LOAD 0x000000 0x00048000 0x00048000 0xe6aff14 0xe6aff14 R E
0x1000*
LOAD 0xe6b0000 0x0e6f8000 0x0e6f8000 0x3a0db7c 0x615c3cc RW
0x1000
DYNAMIC 0xe706618 0x0e74e618 0x0e74e618 0x000f0 0x000f0 RW 0x4
NOTE 0x000128 0x00048128 0x00048128 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Below are the map details when my executable is valground.
cat /proc/5525/maps
*00110000-00111000 r-xp 00000000 00:00 0 [vdso]*
60003000-60403000 rwxp 00000000 00:00 0
98000000-98267000 r-xp 00001000 08:01 303195
/home/vijay/Downloads/valgrind/lib/valgrind/memcheck-x86-linux
98268000-9826a000 rw-p 00268000 08:01 303195
/home/vijay/Downloads/valgrind/lib/valgrind/memcheck-x86-linux
9826a000-98d19000 rw-p 00000000 00:00 0 [heap]
bffdf000-c0000000 rw-p 00000000 00:00 0 [stack]
Some valgrind segment traces in gdb.
(gdb) r
Starting program: /home/vijay/Downloads/valgrind/bin/valgrind -v
../../boxer.shared
process 5560 is executing new program:
/home/vijay/Downloads/valgrind/lib/valgrind/memcheck-x86-linux
Breakpoint 1, add_segment (seg=0x98a2bc8c) at
m_aspacemgr/aspacemgr-linux.c:1468 * =========> segment corresponding to
vdso*
1468 Addr sStart = seg->start;
1: *seg = {kind = SkAnonV, start = 1114112, end = 1118207, smode = SmFixed,
dev = 0, ino = 0, offset = 0, mode = 0, fnIdx = -1, hasR = 1 '\001', hasW =
0 '\000',
hasX = 1 '\001', hasT = 0 '\000', isCH = 0 '\000', mark = 0 '\000'}
(gdb) bt
#0 add_segment (seg=0x98a2bc8c) at m_aspacemgr/aspacemgr-linux.c:1468
#1 0x9804f513 in read_maps_callback (addr=1114112, len=4096, prot=5,
dev=0, ino=<value optimized out>, offset=0, filename=0x0) at
m_aspacemgr/aspacemgr-linux.c:1584
#2 0x9804df7e in parse_procselfmaps (record_mapping=<value optimized out>,
record_gap=<value optimized out>) at m_aspacemgr/aspacemgr-linux.c:3334
#3 0x98050001 in vgPlain_am_startup (sp_at_startup=3221223472) at
m_aspacemgr/aspacemgr-linux.c:1716
#4 0x98030589 in valgrind_main (argc=<value optimized out>, argv=<value
optimized out>, envp=<value optimized out>) at m_main.c:1525
#5 0x98034c7d in _start_in_C_linux (pArgc=0xbffff830) at m_main.c:2785
#6 0x9802f94c in _start ()
(gdb) f 1
#1 0x9804f513 in read_maps_callback (addr=1114112, len=4096, prot=5,
dev=0, ino=<value optimized out>, offset=0, filename=0x0) at
m_aspacemgr/aspacemgr-linux.c:1584
1584 add_segment( &seg );
(gdb) p /x addr
$1 = 0x110000
(gdb) p /x addr + len
$2 = 0x111000
(gdb) b aspacemgr-linux.c:1742
Breakpoint 2 at 0x980505c9: file m_aspacemgr/aspacemgr-linux.c, line 1742.
(gdb) c
Continuing.
*My Executable's load section requires to be mapped at a fixed location
0x48000*
Breakpoint 2, vgPlain_am_get_advisory (req=0x98a2bb04, forClient=1 '\001',
ok=0x98a2bb27 "\230\250\273\242\230\005") at
m_aspacemgr/aspacemgr-linux.c:1799
1799 Addr reqStart = req->rkind==MAny ? 0 : req->start;
(gdb) p *req
$4 = {rkind = MFixed, start = 294912, len = 241893376}
(gdb) p /x req->start
$5 = 0x48000
(gdb)
where iLow = 1, iHigh = 3
(gdb) p nsegments[1]
$9 = {kind = SkFree, start = 16384, end = 1114111, smode = SmFixed, dev =
0, ino = 0, offset = 0, mode = 0, fnIdx = -1, hasR = 0 '\000', hasW = 0
'\000', hasX = 0 '\000',
hasT = 0 '\000', isCH = 0 '\000', mark = 0 '\000'}
*(gdb) p nsegments[2]
$10 = {kind = SkAnonV, start = 1114112, end = 1118207, smode = SmFixed, dev
= 0, ino = 0, offset = 0, mode = 0, fnIdx = -1, hasR = 1 '\001', hasW = 0
'\000', hasX = 1 '\001',
hasT = 0 '\000', isCH = 0 '\000', mark = 0 '\000'} ==========> This
segment has been mapped already by valgrind and more specifically by vdso.
*(gdb) p nsegments[3]
$11 = {kind = SkFree, start = 1118208, end = 1610620927, smode = SmFixed,
dev = 0, ino = 0, offset = 0, mode = 0, fnIdx = -1, hasR = 0 '\000', hasW =
0 '\000',
hasX = 0 '\000', hasT = 0 '\000', isCH = 0 '\000', mark = 0 '\000'}
(gdb)
Is it possible to relocate vdso ? Eagerly awaiting your reply :)
Thanks
Vijay Nag
|
|
From: John R. <jr...@bi...> - 2012-09-28 12:43:47
|
> Valgrind's VDSO collides with my executables load section. Is it possible to relocate load VDSO ? [vdso] was put there by the kernel during the execve() which created the current address-space layout, before valgrind itself executes any instruction. If you don't like [vdso] there, then you should adjust /proc/sys/vm/legacy_va_layout . (Still, valgrind's address-space manager should handle the collision better.) > > Below are my executables phdr details. You left out the most important part, which is whether the file is ET_EXEC or ET_DYN: $ readelf --file-header ./my_app | grep Type: > Program Headers: > * LOAD 0x000000 0x00048000 0x00048000 0xe6aff14 0xe6aff14 R E 0x1000* The VirtAddr of PT_LOAD for an ET_DYN module is relocatable by sliding the whole module. The VirtAddr of PT_LOAD for an ET_EXEC module must not be changed. -- |
|
From: vijay n. <vi...@gm...> - 2012-09-28 12:56:31
|
Hi John, Turning off vdso(*echo 0 > /proc/sys/vm/vdso_enabled)* in the kernel helped to load the executable at the desired fixed location. However valgrind is failing to load the debuginfo. ==22096== Memcheck, a memory error detector ==22096== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==22096== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==22096== Command: myapp ==22096== --22096-- Valgrind options: --22096-- -v --22096-- Contents of /proc/version: --22096-- Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 --22096-- Arch and hwcaps: X86, x86-sse1-sse2 --22096-- Page sizes: currently 4096, max supported 4096 --22096-- Valgrind library directory: /home/vijay/Downloads/valgrind/lib/valgrind --22096-- Reading syms from /home/vijay/Downloads/myapp (0x48000) ==22096== warning: mmap failed on /home/vijay/Downloads/myapp ==22096== no symbols or debug info loaded Any workaround for this ? Is it advisable to turn off VDSO ? Btw app type is EXEC vijay:/home/vijay/Downloads/valgrind/bin]$ readelf --file-header myapp | grep Type Type: EXEC (Executable file) Vijay Nag On Fri, Sep 28, 2012 at 6:14 PM, John Reiser <jr...@bi...> wrote: > > Valgrind's VDSO collides with my executables load section. Is it > possible to relocate load VDSO ? > > [vdso] was put there by the kernel during the execve() which created > the current address-space layout, before valgrind itself executes any > instruction. > If you don't like [vdso] there, then you should adjust > /proc/sys/vm/legacy_va_layout . > (Still, valgrind's address-space manager should handle the collision > better.) > > > > > Below are my executables phdr details. > > You left out the most important part, which is whether the file is ET_EXEC > or ET_DYN: > $ readelf --file-header ./my_app | grep Type: > > > Program Headers: > > > * LOAD 0x000000 0x00048000 0x00048000 0xe6aff14 0xe6aff14 R E > 0x1000* > > The VirtAddr of PT_LOAD for an ET_DYN module is relocatable by sliding > the whole module. > The VirtAddr of PT_LOAD for an ET_EXEC module must not be changed. > > -- > > > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |