|
From: Josef W. <Jos...@gm...> - 2003-12-17 09:53:39
|
On Tuesday 16 December 2003 23:52, Jeremy Fitzhardinge wrote: > On Tue, 2003-12-16 at 11:10, Josef Weidendorfer wrote: > > 41000c10 <_start>: > > 41000c10: 89 e0 mov %esp,%eax > > 41000c12: e8 f9 00 00 00 call 41000d10 <_dl_start> > > You mean it's the call _dl_start? Does '--pointercheck=no' make a > difference? Yes, I think it's the call - somehow. And you are right, --pointercheck=no does change things! Now I get: =================================================== ==4743== For more details, rerun with: -v ==4743== valgrind: vg_scheduler.c:1171 (vgPlain_scheduler): Assertion `done_this_time >= 0' failed. ==4743== at 0xB8029505: vgPlain_skin_assert_fail (vg_mylibc.c:1161) ==4743== by 0xB8029504: assert_fail (vg_mylibc.c:1157) ==4743== by 0xB8029542: vgPlain_core_assert_fail (vg_mylibc.c:1168) ==4743== by 0xB800EDB4: vgPlain_scheduler (vg_scheduler.c:1206) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==4743== at 0x81000C10: (within /lib/ld-2.3.2.so) ======================================== > I'm guessing it's something strange about your instrumentation - can you > post the output of '--trace-codegen=10001'? It shouldn't be very > long... That's another thing. --tracegen gives me nothing. If I do e.g. "valgrind -- tool=none --trace-codegen ls &>log", code generation printout in log starts at 0x81000D10. But I know for sure that my instrumentation is already called for BB 0x81000C10, as the "mov" at 0x81000C10 calls the cache simulator (seen when raising verbosity of my tool with --ct-verbose). > [Usefull info for debugging valgrind] Thanks. I will check this out later. > > Oh, I misunderstood. I thought Valgrind and the client run somehow in > > different processes and different address spaces with FV... ? > > No. I use the terms "client address space" and "Valgrind address > space", but they're both just sub-ranges within the one process address > space as far as the kernel is concerned. OK. My understanding of things should be correct now again ;-) BTW: The auto-generated stage2.lds is working fine here on Suse 9.0. Josef |