http://sourceware.org/gdb/wiki/ProcessRecord
On Oct 30, 5:47 am, "Boehm, Hans" 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
> > 0x7789f2f2.
> > > Process record: failed to record execution log.
>
> > > Program received signal SIGTRAP, Trace/breakpoint trap.
> > > 0x7789f2f0 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=0x7fffc8e8) 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 0x77612e5a because it can't get
> > the value of the segment register.
> > warning: Process record ignores the memory change of
> > instruction at address 0x7784e8c3 because it can't get
> > the value of the segment register.
> > Process record doesn't support instruction 0xfae at address
> > 0x77862c00.
> > Process record: failed to record execution log.
>
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x77862c00 in getcontext () from
> > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> > (gdb) bt
> > #0 0x77862c00 in getcontext () from
> > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> > #1 0x77b96cfa in GC_with_callee_saves_pushed
> > (fn=, arg=0x7fffc73c "") at ../mach_dep.c:194
> > #2 0x77b8e795 in GC_push_roots (all= > out>, cold_gc_frame=0x7fffc73c "") at ../mark_rts.c:790
> > #3 0x77b8df0c in GC_mark_some
> > (cold_gc_frame=0x7fffc73c "") at ../mark.c:359
> > #4 0x77b853f8 in GC_stopped_mark
> > (stop_func=0x77b846d0 ) at ../alloc.c:602
> > #5 0x77b8568d in GC_try_to_collect_inner
> > (stop_func=0x77b846d0 ) at ../alloc.c:421
> > #6 0x77b905c2 in GC_init () at ../misc.c:843
> > #7 0x00400788 in main (argc=1, argv=0x7fffc8e8)
> > 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
