http://sourceware.org/gdb/wiki/ProcessRecord
On Oct 30, 5:47 am, "Boehm, Hans" <hans.bo...@hp.com> wrote: > There may be an easy GC-specific workaound, int that you can probably build > it with -DNO_GETCONTEXT. Or you might be able to link statically against > libc? But this doesn't sound like this will be the last such problem. It > sounds to me like these things really need to get fixed in gdb. > > Hans > > > -----Original Message----- > > From: gc-boun...@napali.hpl.hp.com > > [mailto:gc-boun...@napali.hpl.hp.com] On Behalf Of Ludovic Courtès > > Sent: Wednesday, October 28, 2009 3:54 PM > > To: g...@napali.hpl.hp.com > > Cc: bug-...@gnu.org > > Subject: [Gc] Re: GDB 7's process record/replay & BDW-GC > > > Hi, > > > l...@gnu.org (Ludovic Courtès) writes: > > > > Process record doesn't support instruction 0xf6e at address > > 0x7ffff789f2f2. > > > Process record: failed to record execution log. > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > > 0x00007ffff789f2f0 in memset () from > > > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 > > > I should have started with that: a web search shows that it's > > a known issue, not specific to libgc: > > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10743 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550710 > > > The suggested workaround allows it to go a bit further: > > > --8<---------------cut here---------------start------------->8--- > > Breakpoint 1, main (argc=1, argv=0x7fffffffc8e8) at ,,t.c:6 > > 6 GC_INIT (); > > (gdb) set __x86_64_preferred_memory_instruction=0 > > (gdb) record > > (gdb) n > > warning: Process record ignores the memory change of > > instruction at address 0x7ffff7612e5a because it can't get > > the value of the segment register. > > warning: Process record ignores the memory change of > > instruction at address 0x7ffff784e8c3 because it can't get > > the value of the segment register. > > Process record doesn't support instruction 0xfae at address > > 0x7ffff7862c00. > > Process record: failed to record execution log. > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x00007ffff7862c00 in getcontext () from > > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 > > (gdb) bt > > #0 0x00007ffff7862c00 in getcontext () from > > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 > > #1 0x00007ffff7b96cfa in GC_with_callee_saves_pushed > > (fn=<value optimized out>, arg=0x7fffffffc73c "") at ../mach_dep.c:194 > > #2 0x00007ffff7b8e795 in GC_push_roots (all=<value optimized > > out>, cold_gc_frame=0x7fffffffc73c "") at ../mark_rts.c:790 > > #3 0x00007ffff7b8df0c in GC_mark_some > > (cold_gc_frame=0x7fffffffc73c "") at ../mark.c:359 > > #4 0x00007ffff7b853f8 in GC_stopped_mark > > (stop_func=0x7ffff7b846d0 <GC_never_stop_func>) at ../alloc.c:602 > > #5 0x00007ffff7b8568d in GC_try_to_collect_inner > > (stop_func=0x7ffff7b846d0 <GC_never_stop_func>) at ../alloc.c:421 > > #6 0x00007ffff7b905c2 in GC_init () at ../misc.c:843 > > #7 0x0000000000400788 in main (argc=1, argv=0x7fffffffc8e8) > > at ,,t.c:6 --8<---------------cut > > here---------------end--------------->8--- > > > That's the 'stmxcsr' instruction, apparently an MMX2 > > instruction, unconditionally used by the linux/x86_64 > > getcontext(3) implementation. > > > I find it surprising that getcontext(3) doesn't have a > > mechanism akin to '__x86_64_preferred_memory_instruction' to > > choose whether or not to use > > MMX2 instructions. > > > Comments? > > > Thanks, > > Ludo'. > > > _______________________________________________ > > Gc mailing list > > g...@linux.hpl.hp.com > >http://www.hpl.hp.com/hosted/linux/mail-archives/gc/ _______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb