On Fri, Nov 04, 2005 at 01:21:51PM +0000, Kailash Sethuraman wrote: > One of the biggest motivations for me is that gdb on netbsd has been > broken for as long as I can remember. With Helgrind we can help thread > debugging a LOT. > So i really want to see this go through. Actually i should have a few > hours tonight and on the weekend.
I just checked out, but I'm having problems right away. I asked spoty, but he has no idea either. Maybe you have an idea what's going wrong here? It's been too long for me :( [EMAIL PROTECTED] ./valgrind ls ~/foo vg4nbsd/valgrind/coregrind info.exe_end = 0xbfbff000 info.exe_base = 0xb0000000 info.map_base = 0xb1000000 valgrind_lib = /home/sjamaan/src/vg4nbsd/valgrind/.in_place In load_ELF! in pt_hdr info->phdr = ph->p_vaddr + ebase; (0xb0000034 + 0x0 = 0xb0000034) in pt_load minaddr: b0000000 in pt_load in pt_dynamic pt_dynamic_addr = 0xb00eabb8 [this must match obj->dynamic in ld.so_elf] interp_addr = 0x0 interp = 0x8117040 doing mmap here after mmap and mapelf here info interp_base = 0xb1000000 info->init_eip: b1002604init sp : bfbff898 The argu is ./valgrind auxv[0].u.a_val : 0, auxv[0].a_type : 0 Space for auxv 14 sizeof delta :112 , sizeof auxv : 8 doing auxv 0xbfbff8cc 65281: 0x3 new auxv 0xbfbff8cc 65281: 0x3 doing auxv 0xbfbff8d4 65282: 0x4 new auxv 0xbfbff8d4 65282: 0x4 doing auxv 0xbfbff8dc 3: 0xb0000034 seen 1 new auxv 0xbfbff8dc 3: 0xb0000034 doing auxv 0xbfbff8e4 5: 0x6 seen 2 new auxv 0xbfbff8e4 5: 0x6 doing auxv 0xbfbff8ec 7: 0xb1000000 seen 4 new auxv 0xbfbff8ec 7: 0xb1000000 doing auxv 0xbfbff8f4 9: 0xb0000ec8 seen 8 new auxv 0xbfbff8f4 9: 0xb0000ec8 doing auxv 0xbfbff8fc 6: 0x1000 new auxv 0xbfbff8fc 6: 0x1000 doing auxv 0xbfbff904 4: 0x20 new auxv 0xbfbff904 4: 0x20 doing auxv 0xbfbff90c 8: 0x0 new auxv 0xbfbff90c 8: 0x0 doing auxv 0xbfbff914 2000: 0x3e8 new auxv 0xbfbff914 2000: 0x3e8 doing auxv 0xbfbff91c 2001: 0x3e8 new auxv 0xbfbff91c 2001: 0x3e8 doing auxv 0xbfbff924 2002: 0x64 new auxv 0xbfbff924 2002: 0x64 doing auxv 0xbfbff92c 2003: 0x64 new auxv 0xbfbff92c 2003: 0x64 after fix_auxb ---------- launch stage 2 ---------- eip=0xb1002604 esp=0xbfbff828 mapping 0x0- 0x8048000 ---p 00:00 3137405 mapping 0x8048000- 0x805f000 r-xp 0b:01 7998544 mapping 0x805f000- 0x8060000 rw-p 0b:01 7998544 mapping 0x8060000- 0x811a000 rw-p 00:00 0 mapping 0x811a000-0x4805f000 ---p 00:00 3137405 mapping 0x4805f000-0x48060000 r-xs 00:00 0 mapping 0x48060000-0x48061000 rw-p 00:00 0 mapping 0x48061000-0xb0000000 ---p 00:00 3137405 mapping 0xb0000000-0xb00ea000 r-xp 0b:01 8000696 mapping 0xb00ea000-0xb00eb000 rw-p 0b:01 8000696 mapping 0xb00eb000-0xb0543000 rw-p 00:00 0 mapping 0xb0543000-0xb1000000 ---p 00:00 3137405 mapping 0xb1000000-0xb100a000 r-xp 00:00 6549762 mapping 0xb100a000-0xb100b000 rw-p 00:00 6549762 mapping 0xb100b000-0xb100c000 rw-p 00:00 0 mapping 0xbdc00000-0xbfbf0000 rw-p 00:00 0 mapping 0xbfbf0000-0xbfc00000 rw-p 00:00 0 jumping to stage 2 esp : bfbff828 eip : b1002604 In stage 2 main! dooing debuglog startup --1957:1:debuglog DebugLog system started by Stage 2 (main), level 5 logging requested after debuglog startup --1957:1:main Doing scan_auxv() The argu is ./valgrind --1957:1:main Preprocess command line opts --1957:1:main Loading tool Can't open tool "memcheck": /home/sjamaan/src/vg4nbsd/valgrind/.in_place/vgtool_memcheck.so: Undefined symbol "vgPlain_assert_fail" (symnum = 53) valgrind: couldn't load tool Can't open /home/sjamaan/src/vg4nbsd/valgrind/.in_place: Cannot allocate memory (installation problem?) (Of course, there's more than enough memory in this box) Greetz, Peter -- http://www.student.ru.nl/peter.bex -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth
pgptCDQG6iTmz.pgp
Description: PGP signature
