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-gdb@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
