|
From: Bart V. A. <bar...@gm...> - 2007-01-13 20:33:55
|
While porting drd from x86 to amd64, I noticed that while
VG_(find_seginfo)() works on x86 for symbols in a BSS section, it doesn't
return any info on amd64. With the test program drd/tests/fp_race I get the
following output on x86:
...
Allocation context: s_d3 (offset 0, size 8) in fp_race, NONE:BSS
...
But this is what I get on amd64:
...
Allocation context: unknown
...
The cause of this difference in output is that VG_(find_seginfo)(&s_d3)
returns a null pointer on amd64. There is symbol information for s_d3 in the
fp_race executable however:
$ readelf -a drd/tests/fp_race|grep s_d3
66: 00000000006020f8 8 OBJECT LOCAL DEFAULT 26 s_d3
$ objdump -x drd/tests/fp_race|grep s_d3
00000000006020f8 l O .bss 0000000000000008 s_d3
$ nm drd/tests/fp_race|grep s_d3
00000000006020f8 b s_d3
Is the above output enough to explain why VG_(find_seginfo)(&s_d3) == 0 on
amd64 ? Are there any known issues regarding to looking up symbol
information in BSS sections on amd64 ?
Bart.
|
|
From: Julian S. <js...@ac...> - 2007-01-13 22:28:59
|
> Is the above output enough to explain why VG_(find_seginfo)(&s_d3) == 0 on > amd64 ? Are there any known issues regarding to looking up symbol > information in BSS sections on amd64 ? I had a look at the stuff in readelf.c for data symbol reading, and I can't say I really understand it. It appears to be based on the assumption that the data section is mapped immediately after the text section. If that's so it may require some redesign to make it work reliably. Can you send the "Memory layout at client shutdown" shown when you run with -d (you may have to apply r6519 to make it work - I just found it to be partially broken.) This is so we can see where in fact the data section did get mapped relative to the executable. J |
|
From: Bart V. A. <bar...@gm...> - 2007-01-14 14:34:48
|
On 1/13/07, Julian Seward <js...@ac...> wrote: > > > > Is the above output enough to explain why VG_(find_seginfo)(&s_d3) == 0 > on > > amd64 ? Are there any known issues regarding to looking up symbol > > information in BSS sections on amd64 ? > > I had a look at the stuff in readelf.c for data symbol reading, and I > can't > say I really understand it. It appears to be based on the assumption that > the data section is mapped immediately after the text section. If that's > so it may require some redesign to make it work reliably. > > Can you send the "Memory layout at client shutdown" shown when you run > with > -d (you may have to apply r6519 to make it work - I just found it to be > partially broken.) This is so we can see where in fact the data section > did get mapped relative to the executable. > > J > This is the last part of the output that appears when running the drd tool combined with option -d: $ svn update Fetching external item into 'VEX' External at revision 1727. At revision 6519. $ VALGRIND_LIB=.in_place coregrind/valgrind -d --tool=drd drd/tests/fp_race ... --3940:1:syswrap- thread_wrapper(tid=1): exit --3940:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper --3940:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing --3940:1:main entering VG_(shutdown_actions_NORETURN) --3940:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client shutdown (72 segments, 11 segnames) --3940:1:aspacem ( 0) /home/bart/software/valgrind-svn/drd/drd-amd64-linux --3940:1:aspacem ( 1) /home/bart/software/valgrind-svn/drd/tests/fp_race --3940:1:aspacem ( 2) /lib64/ld-2.5.so --3940:1:aspacem ( 3) /home/bart/software/valgrind-svn/coregrind/vgpreload_core-amd64-linux.so --3940:1:aspacem ( 4) /home/bart/software/valgrind-svn/drd/vgpreload_drd- amd64-linux.so --3940:1:aspacem ( 6) /lib64/libpthread-2.5.so --3940:1:aspacem ( 7) /usr/lib64/libstdc++.so.6.0.8 --3940:1:aspacem ( 8) /lib64/libm-2.5.so --3940:1:aspacem ( 9) /lib64/libgcc_s.so.1 --3940:1:aspacem (10) /lib64/libc-2.5.so --3940:1:aspacem 0: RSVN 0000000000-00003FFFFF 4194304 ----- SmFixed --3940:1:aspacem 1: file 0000400000-0000400FFF 4096 r-xT- d=0x802 i=936203 o=0 (1) --3940:1:aspacem 2: RSVN 0000401000-0000600FFF 2097152 ----- SmFixed --3940:1:aspacem 3: file 0000601000-0000601FFF 4096 r---- d=0x802 i=936203 o=4096 (1) --3940:1:aspacem 4: file 0000602000-0000602FFF 4096 rw--- d=0x802 i=936203 o=8192 (1) --3940:1:aspacem 5: RSVN 0000603000-0003FFFFFF 57m ----- SmFixed --3940:1:aspacem 6: file 0004000000-000401BFFF 114688 r-xT- d=0x802 i=489602 o=0 (2) --3940:1:aspacem 7: anon 000401C000-000401EFFF 12288 rw--- --3940:1:aspacem 8: 000401F000-0004042FFF 147456 --3940:1:aspacem 9: anon 0004043000-0004045FFF 12288 rw--- --3940:1:aspacem 10: anon 0004046000-0004145FFF 1048576 rwx-H --3940:1:aspacem 11: 0004146000-000421BFFF 876544 --3940:1:aspacem 12: file 000421C000-000421DFFF 8192 rw--- d=0x802 i=489602 o=114688 (2) --3940:1:aspacem 13: anon 000421E000-000421EFFF 4096 rwx-- --3940:1:aspacem 14: RSVN 000421F000-0004A1DFFF 8384512 ----- SmLower --3940:1:aspacem 15: file 0004A1E000-0004A1EFFF 4096 r-x-- d=0x802 i=936571 o=0 (3) --3940:1:aspacem 16: file 0004A1F000-0004C1DFFF 2093056 ----- d=0x802 i=936571 o=4096 (3) --3940:1:aspacem 17: file 0004C1E000-0004C1EFFF 4096 r---- d=0x802 i=936571 o=0 (3) --3940:1:aspacem 18: file 0004C1F000-0004C1FFFF 4096 rw--- d=0x802 i=936571 o=4096 (3) --3940:1:aspacem 19: file 0004C20000-0004C25FFF 24576 r-xT- d=0x802 i=936199 o=0 (4) --3940:1:aspacem 20: file 0004C26000-0004E24FFF 2093056 ----- d=0x802 i=936199 o=24576 (4) --3940:1:aspacem 21: file 0004E25000-0004E25FFF 4096 r---- d=0x802 i=936199 o=20480 (4) --3940:1:aspacem 22: file 0004E26000-0004E26FFF 4096 rw--- d=0x802 i=936199 o=24576 (4) --3940:1:aspacem 23: file 0004E27000-0004E3CFFF 90112 r-xT- d=0x802 i=489635 o=0 (6) --3940:1:aspacem 24: file 0004E3D000-000503BFFF 2093056 ----- d=0x802 i=489635 o=90112 (6) --3940:1:aspacem 25: file 000503C000-000503DFFF 8192 rw--- d=0x802 i=489635 o=86016 (6) --3940:1:aspacem 26: anon 000503E000-0005041FFF 16384 rw--- --3940:1:aspacem 27: file 0005042000-0005124FFF 929792 r-xT- d=0x802 i=429416 o=0 (7) --3940:1:aspacem 28: file 0005125000-0005324FFF 2097152 ----- d=0x802 i=429416 o=929792 (7) --3940:1:aspacem 29: file 0005325000-000532AFFF 24576 r---- d=0x802 i=429416 o=929792 (7) --3940:1:aspacem 30: file 000532B000-000532DFFF 12288 rw--- d=0x802 i=429416 o=954368 (7) --3940:1:aspacem 31: anon 000532E000-000533FFFF 73728 rw--- --3940:1:aspacem 32: file 0005340000-0005394FFF 348160 r-xT- d=0x802 i=489617 o=0 (8) --3940:1:aspacem 33: file 0005395000-0005593FFF 2093056 ----- d=0x802 i=489617 o=348160 (8) --3940:1:aspacem 34: file 0005594000-0005595FFF 8192 rw--- d=0x802 i=489617 o=344064 (8) --3940:1:aspacem 35: file 0005596000-00055A2FFF 53248 r-xT- d=0x802 i=489645 o=0 (9) --3940:1:aspacem 36: file 00055A3000-00057A1FFF 2093056 ----- d=0x802 i=489645 o=53248 (9) --3940:1:aspacem 37: file 00057A2000-00057A3FFF 8192 rw--- d=0x802 i=489645 o=49152 (9) --3940:1:aspacem 38: file 00057A4000-00058DCFFF 1282048 r-xT- d=0x802 i=489609 o=0 (10) --3940:1:aspacem 39: file 00058DD000-0005ADBFFF 2093056 ----- d=0x802 i=489609 o=1282048 (10) --3940:1:aspacem 40: file 0005ADC000-0005ADEFFF 12288 r---- d=0x802 i=489609 o=1277952 (10) --3940:1:aspacem 41: file 0005ADF000-0005AE0FFF 8192 rw--- d=0x802 i=489609 o=1290240 (10) --3940:1:aspacem 42: anon 0005AE1000-0005AE5FFF 20480 rw--- --3940:1:aspacem 43: anon 0005AE6000-0005AE6FFF 4096 ----- --3940:1:aspacem 44: anon 0005AE7000-00062E6FFF 8388608 rw--- --3940:1:aspacem 45: 00062E7000-0037FFFFFF 797m --3940:1:aspacem 46: FILE 0038000000-0038018FFF 102400 r-x-- d=0x802 i=936183 o=0 (0) --3940:1:aspacem 47: file 0038019000-0038019FFF 4096 r-x-- d=0x802 i=936183 o=102400 (0) --3940:1:aspacem 48: FILE 003801A000-0038161FFF 1343488 r-x-- d=0x802 i=936183 o=106496 (0) --3940:1:aspacem 49: 0038162000-0038360FFF 2093056 --3940:1:aspacem 50: FILE 0038361000-0038362FFF 8192 rw--- d=0x802 i=936183 o=1445888 (0) --3940:1:aspacem 51: ANON 0038363000-0038E9DFFF 11m rw--- --3940:1:aspacem 52: 0038E9E000-0401FFFFFF 15505m --3940:1:aspacem 53: RSVN 0402000000-0402000FFF 4096 ----- SmFixed --3940:1:aspacem 54: ANON 0402001000-0402770FFF 7798784 rwx-- --3940:1:aspacem 55: ANON 0402771000-0402772FFF 8192 ----- --3940:1:aspacem 56: ANON 0402773000-0402782FFF 65536 rwx-- --3940:1:aspacem 57: ANON 0402783000-0402784FFF 8192 ----- --3940:1:aspacem 58: ANON 0402785000-0403787FFF 16m rwx-- --3940:1:aspacem 59: ANON 0403788000-0403789FFF 8192 ----- --3940:1:aspacem 60: ANON 040378A000-0403799FFF 65536 rwx-- --3940:1:aspacem 61: ANON 040379A000-040379BFFF 8192 ----- --3940:1:aspacem 62: ANON 040379C000-04037ABFFF 65536 rwx-- --3940:1:aspacem 63: 04037AC000-07FE800FFF 16304m --3940:1:aspacem 64: RSVN 07FE801000-07FEFFDFFF 8376320 ----- SmUpper --3940:1:aspacem 65: anon 07FEFFE000-07FF000FFF 12288 rwx-- --3940:1:aspacem 66: 07FF001000-07FFFFFFFF 15m --3940:1:aspacem 67: RSVN 0800000000-7FFFD4BFEFFF 131039g ----- SmFixed --3940:1:aspacem 68: ANON 7FFFD4BFF000-7FFFD4C14FFF 90112 rw--- --3940:1:aspacem 69: RSVN 7FFFD4C15000-FFFFFFFFFF5FFFFF 16383e ----- SmFixed --3940:1:aspacem 70: ANON FFFFFFFFFF600000-FFFFFFFFFFDFFFFF 8388608 ----- --3940:1:aspacem 71: RSVN FFFFFFFFFFE00000-FFFFFFFFFFFFFFFF 2097152 ----- SmFixed --3940:1:aspacem >>> ==3940== ==3940== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 3) --3940:1:core_os VG_(terminate_NORETURN)(tid=1) Bart. |
|
From: Julian S. <js...@ac...> - 2007-01-15 16:22:46
|
Here are the relevant bits: > ( 1) /home/bart/software/valgrind-svn/drd/tests/fp_race > 1: file 0000400000-0000400FFF 4096 r-xT- d=0x802 i=936203 o=0 (1) > 2: RSVN 0000401000-0000600FFF 2097152 ----- SmFixed > 3: file 0000601000-0000601FFF 4096 r---- d=0x802 i=936203 o=4096 (1) > 4: file 0000602000-0000602FFF 4096 rw--- d=0x802 i=936203 o=8192 (1) The file "(1)", which is /home/bart/software/valgrind-svn/drd/tests/fp_race, is mapped 3 times. The text segment (r-xT-) at 0x400000, readonly data at 0x601000 and readwrite data at 0x602000. Given that the text segment is only one page long, there is a 2M hole between it and the data areas which I'm sure can't be helping the data-symbol reader. It would be interesting to see the same information for a run where data symbol reading did succeed (on x86). J |
|
From: Bart V. A. <bar...@gm...> - 2007-01-14 16:42:08
|
On 1/14/07, Julian Seward <js...@ac...> wrote: > > > Here are the relevant bits: > > > ( 1) /home/bart/software/valgrind-svn/drd/tests/fp_race > > > 1: file 0000400000-0000400FFF 4096 r-xT- d=0x802 > i=936203 o=0 (1) > > 2: RSVN 0000401000-0000600FFF 2097152 ----- SmFixed > > 3: file 0000601000-0000601FFF 4096 r---- d=0x802 i=936203 o=4096 > (1) > > 4: file 0000602000-0000602FFF 4096 rw--- d=0x802 i=936203 o=8192 > (1) > > The file "(1)", which > is /home/bart/software/valgrind-svn/drd/tests/fp_race, > is mapped 3 times. The text segment (r-xT-) at 0x400000, readonly data at > 0x601000 and readwrite data at 0x602000. Given that the text segment is > only one page long, there is a 2M hole between it and the data areas which > I'm sure can't be helping the data-symbol reader. > > It would be interesting to see the same information for a run where data > symbol reading did succeed (on x86). > > J > On the same platform (amd64, openSUSE 10.2) I have rebuilt drd/test/fp_race with flag -m32 instead of -m64. VG_(find_seginfo)(&s_d3) succeeds in this case, and the memory layout at client shutdown is as follows for the 32-bit executable: $ VALGRIND_LIB=.in_place coregrind/valgrind -d --tool=drd drd/tests/fp_race-m32 ... ==3527== Conflicting load by main at 0x0804A078 size 8 ==3527== at 0x8048898: main (fp_race.cpp:112) ==3527== Allocation context: s_d3 (offset 0, size 8) in drd/tests/fp_race-m32, NONE:BSS ==3527== Other segment start (thread_func) ==3527== (thread finished, call stack no longer available) ==3527== Other segment end (thread_func) ==3527== (thread finished, call stack no longer available) ==3527== ==3527== Conflicting store by main at 0x0804A078 size 8 ==3527== at 0x804889E: main (fp_race.cpp:112) ==3527== Allocation context: s_d3 (offset 0, size 8) in drd/tests/fp_race-m32, NONE:BSS ==3527== Other segment start (thread_func) ==3527== (thread finished, call stack no longer available) ==3527== Other segment end (thread_func) ==3527== (thread finished, call stack no longer available) --3527:1:syswrap- thread_wrapper(tid=1): exit --3527:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper --3527:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing --3527:1:main entering VG_(shutdown_actions_NORETURN) --3527:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client shutdown (65 segments, 11 segnames) --3527:1:aspacem ( 0) /home/bart/software/valgrind-svn/drd/drd-x86-linux --3527:1:aspacem ( 1) /home/bart/software/valgrind-svn/drd/tests/fp_race-m32 --3527:1:aspacem ( 2) /lib/ld-2.5.so --3527:1:aspacem ( 3) /home/bart/software/valgrind-svn/coregrind/vgpreload_core-x86-linux.so --3527:1:aspacem ( 4) /home/bart/software/valgrind-svn/drd/vgpreload_drd- x86-linux.so --3527:1:aspacem ( 6) /lib/libpthread-2.5.so --3527:1:aspacem ( 7) /usr/lib/libstdc++.so.6.0.8 --3527:1:aspacem ( 8) /lib/libm-2.5.so --3527:1:aspacem ( 9) /lib/libgcc_s.so.1 --3527:1:aspacem (10) /lib/libc-2.5.so --3527:1:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --3527:1:aspacem 1: ANON 0004000000-00040FFFFF 1048576 rwx-- --3527:1:aspacem 2: file 0004100000-000411AFFF 110592 r-xT- d=0x802 i=65285 o=0 (2) --3527:1:aspacem 3: file 000411B000-000411CFFF 8192 rw--- d=0x802 i=65285 o=106496 (2) --3527:1:aspacem 4: ANON 000411D000-0004397FFF 2600960 rwx-- --3527:1:aspacem 5: ANON 0004398000-0004399FFF 8192 ----- --3527:1:aspacem 6: ANON 000439A000-00043A9FFF 65536 rwx-- --3527:1:aspacem 7: ANON 00043AA000-00043ABFFF 8192 ----- --3527:1:aspacem 8: ANON 00043AC000-00043FBFFF 327680 rwx-- --3527:1:aspacem 9: anon 00043FC000-00043FCFFF 4096 rw--- --3527:1:aspacem 10: file 00043FD000-00043FDFFF 4096 r-x-- d=0x802 i=936576 o=0 (3) --3527:1:aspacem 11: file 00043FE000-00043FEFFF 4096 r---- d=0x802 i=936576 o=0 (3) --3527:1:aspacem 12: file 00043FF000-00043FFFFF 4096 rw--- d=0x802 i=936576 o=4096 (3) --3527:1:aspacem 13: file 0004400000-0004404FFF 20480 r-xT- d=0x802 i=936185 o=0 (4) --3527:1:aspacem 14: file 0004405000-0004405FFF 4096 r---- d=0x802 i=936185 o=16384 (4) --3527:1:aspacem 15: file 0004406000-0004406FFF 4096 rw--- d=0x802 i=936185 o=20480 (4) --3527:1:aspacem 16: anon 0004407000-0004407FFF 4096 rw--- --3527:1:aspacem 17: ANON 0004408000-0004409FFF 8192 ----- --3527:1:aspacem 18: ANON 000440A000-0004419FFF 65536 rwx-- --3527:1:aspacem 19: ANON 000441A000-000441BFFF 8192 ----- --3527:1:aspacem 20: ANON 000441C000-000442BFFF 65536 rwx-- --3527:1:aspacem 21: file 000442C000-000443FFFF 81920 r-xT- d=0x802 i=65318 o=0 (6) --3527:1:aspacem 22: file 0004440000-0004441FFF 8192 rw--- d=0x802 i=65318 o=77824 (6) --3527:1:aspacem 23: anon 0004442000-0004443FFF 8192 rw--- --3527:1:aspacem 24: file 0004444000-000451CFFF 888832 r-xT- d=0x802 i=429623 o=0 (7) --3527:1:aspacem 25: file 000451D000-000451FFFF 12288 r---- d=0x802 i=429623 o=888832 (7) --3527:1:aspacem 26: file 0004520000-0004521FFF 8192 rw--- d=0x802 i=429623 o=901120 (7) --3527:1:aspacem 27: anon 0004522000-0004527FFF 24576 rw--- --3527:1:aspacem 28: file 0004528000-000454BFFF 147456 r-xT- d=0x802 i=65300 o=0 (8) --3527:1:aspacem 29: file 000454C000-000454DFFF 8192 rw--- d=0x802 i=65300 o=143360 (8) --3527:1:aspacem 30: anon 000454E000-000454EFFF 4096 rw--- --3527:1:aspacem 31: file 000454F000-0004558FFF 40960 r-xT- d=0x802 i=65328 o=0 (9) --3527:1:aspacem 32: file 0004559000-000455AFFF 8192 rw--- d=0x802 i=65328 o=36864 (9) --3527:1:aspacem 33: file 000455B000-0004682FFF 1212416 r-xT- d=0x802 i=65292 o=0 (10) --3527:1:aspacem 34: file 0004683000-0004683FFF 4096 r---- d=0x802 i=65292 o=1212416 (10) --3527:1:aspacem 35: file 0004684000-0004685FFF 8192 rw--- d=0x802 i=65292 o=1216512 (10) --3527:1:aspacem 36: anon 0004686000-0004689FFF 16384 rw--- --3527:1:aspacem 37: 000468A000-0004744FFF 765952 --3527:1:aspacem 38: ANON 0004745000-0005737FFF 15m rwx-- --3527:1:aspacem 39: anon 0005738000-0005837FFF 1048576 rwx-H --3527:1:aspacem 40: 0005838000-00058A4FFF 446464 --3527:1:aspacem 41: ANON 00058A5000-00059A4FFF 1048576 rwx-- --3527:1:aspacem 42: anon 00059A5000-00059A5FFF 4096 ----- --3527:1:aspacem 43: anon 00059A6000-00061A5FFF 8388608 rw--- --3527:1:aspacem 44: 00061A6000-0008047FFF 30m --3527:1:aspacem 45: file 0008048000-0008048FFF 4096 r-xT- d=0x802 i=936138 o=0 (1) --3527:1:aspacem 46: file 0008049000-0008049FFF 4096 r---- d=0x802 i=936138 o=0 (1) --3527:1:aspacem 47: file 000804A000-000804AFFF 4096 rw--- d=0x802 i=936138 o=4096 (1) --3527:1:aspacem 48: anon 000804B000-000804BFFF 4096 rwx-- --3527:1:aspacem 49: RSVN 000804C000-000884AFFF 8384512 ----- SmLower --3527:1:aspacem 50: 000884B000-0037FFFFFF 759m --3527:1:aspacem 51: FILE 0038000000-003801AFFF 110592 r-x-- d=0x802 i=930866 o=0 (0) --3527:1:aspacem 52: file 003801B000-003801BFFF 4096 r-x-- d=0x802 i=930866 o=110592 (0) --3527:1:aspacem 53: FILE 003801C000-003815CFFF 1314816 r-x-- d=0x802 i=930866 o=114688 (0) --3527:1:aspacem 54: 003815D000-003815DFFF 4096 --3527:1:aspacem 55: FILE 003815E000-003815EFFF 4096 rw--- d=0x802 i=930866 o=1429504 (0) --3527:1:aspacem 56: ANON 003815F000-0038BD5FFF 10m rw--- --3527:1:aspacem 57: 0038BD6000-00FE34BFFF 3159m --3527:1:aspacem 58: RSVN 00FE34C000-00FEB49FFF 8380416 ----- SmUpper --3527:1:aspacem 59: anon 00FEB4A000-00FEB4BFFF 8192 rwx-- --3527:1:aspacem 60: 00FEB4C000-00FFB4AFFF 15m --3527:1:aspacem 61: ANON 00FFB4B000-00FFB4DFFF 12288 rw--- --3527:1:aspacem 62: RSVN 00FFB4E000-00FFFFDFFF 4915200 ----- SmFixed --3527:1:aspacem 63: ANON 00FFFFE000-00FFFFEFFF 4096 r-x-- --3527:1:aspacem 64: RSVN 00FFFFF000-00FFFFFFFF 4096 ----- SmFixed --3527:1:aspacem >>> ==3527== ==3527== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 3) --3527:1:core_os VG_(terminate_NORETURN)(tid=1) |
|
From: Julian S. <js...@ac...> - 2007-01-14 18:31:17
|
> On the same platform (amd64, openSUSE 10.2) I have rebuilt drd/test/fp_race > with flag -m32 instead of -m64. VG_(find_seginfo)(&s_d3) succeeds in this > case, and the memory layout at client shutdown is as follows for the 32-bit > executable: > 45: file 0008048000-0008048FFF 4096 r-xT- d=0x802 i=936138 o=0 (1) > 46: file 0008049000-0008049FFF 4096 r---- d=0x802 i=936138 o=0 (1) > 47: file 000804A000-000804AFFF 4096 rw--- d=0x802 i=936138 o=4096 (1) As expected the data segment (r----) has been mapped immediately after the text segment. J |
|
From: Bart V. A. <bar...@gm...> - 2007-03-01 18:42:51
|
One of drd's regression tests still fails on AMD64 because
VG_(find_seginfo)() fails for BSS symbols on AMD64. Are there any
plans to fix this problem ?
bart@athlon:~/software/valgrind-inner> perl tests/vg_regtest drd
-- Running tests in drd/tests -----------------------------------------
fp_race: valgrind ./fp_race
*** fp_race failed (stderr) ***
fp_race2: valgrind ./fp_race -m
pth_cond_race: valgrind ./pth_cond_race
pth_cond_race2: valgrind ./pth_cond_race -m
pth_detached: valgrind ./pth_detached 1 1
pth_detached2: valgrind ./pth_detached 10 10
-- Finished tests in drd/tests -----------------------------------------
---------- Forwarded message ----------
From: Bart Van Assche <bar...@gm...>
Date: Jan 13, 2007 9:33 PM
Subject: VG_(find_seginfo)() on 64-bit platforms
To: Valgrind Developers <val...@li...>
While porting drd from x86 to amd64, I noticed that while
VG_(find_seginfo)() works on x86 for symbols in a BSS section, it
doesn't return any info on amd64. With the test program
drd/tests/fp_race I get the following output on x86:
...
Allocation context: s_d3 (offset 0, size 8) in fp_race, NONE:BSS
...
But this is what I get on amd64:
...
Allocation context: unknown
...
The cause of this difference in output is that
VG_(find_seginfo)(&s_d3) returns a null pointer on amd64. There is
symbol information for s_d3 in the fp_race executable however:
$ readelf -a drd/tests/fp_race|grep s_d3
66: 00000000006020f8 8 OBJECT LOCAL DEFAULT 26 s_d3
$ objdump -x drd/tests/fp_race|grep s_d3
00000000006020f8 l O .bss 0000000000000008 s_d3
$ nm drd/tests/fp_race|grep s_d3
00000000006020f8 b s_d3
Is the above output enough to explain why VG_(find_seginfo)(&s_d3) ==
0 on amd64 ? Are there any known issues regarding to looking up symbol
information in BSS sections on amd64 ?
Bart.
|