RE: Re: GDB 7's process record/replay & BDW-GC

There may be an easy GC-specific workaound, int that you can probably bui=
ld it with -DNO_GETCONTEXT.  Or you might be able to link statically agai=
nst 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=20

> -----Original Message-----
> From: gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/[email protected]=20
> [mailto:gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/[email protected]] On Behalf Of Ludovic Court=E8s
> Sent: Wednesday, October 28, 2009 3:54 PM
> To: gc-o/PNRNCSakrWxDs0y9d3MAC/[email protected]
> Cc: bug-gdb-mXXj517/[email protected]
> Subject: [Gc] Re: GDB 7's process record/replay & BDW-GC
>=20
> Hi,
>=20
> ludo-mXXj517/[email protected] (Ludovic Court=E8s) writes:
>=20
> > Process record doesn't support instruction 0xf6e at address=20
> 0x7ffff789f2f2.
> > Process record: failed to record execution log.
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x00007ffff789f2f0 in memset () from=20
> > /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
>=20
> I should have started with that: a web search shows that it's=20
> a known issue, not specific to libgc:
>=20
>   http://sources.redhat.com/bugzilla/show_bug.cgi?id=3D10743
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D550710
>=20
> The suggested workaround allows it to go a bit further:
>=20
> --8<---------------cut here---------------start------------->8---
> Breakpoint 1, main (argc=3D1, argv=3D0x7fffffffc8e8) at ,,t.c:6
> 6         GC_INIT ();
> (gdb) set __x86_64_preferred_memory_instruction=3D0
> (gdb) record
> (gdb) n
> warning: Process record ignores the memory change of=20
> instruction at address 0x7ffff7612e5a because it can't get=20
> the value of the segment register.
> warning: Process record ignores the memory change of=20
> instruction at address 0x7ffff784e8c3 because it can't get=20
> the value of the segment register.
> Process record doesn't support instruction 0xfae at address=20
> 0x7ffff7862c00.
> Process record: failed to record execution log.
>=20
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff7862c00 in getcontext () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> (gdb) bt
> #0  0x00007ffff7862c00 in getcontext () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> #1  0x00007ffff7b96cfa in GC_with_callee_saves_pushed=20
> (fn=3D<value optimized out>, arg=3D0x7fffffffc73c "") at ../mach_dep.c:=
194
> #2  0x00007ffff7b8e795 in GC_push_roots (all=3D<value optimized=20
> out>, cold_gc_frame=3D0x7fffffffc73c "") at ../mark_rts.c:790
> #3  0x00007ffff7b8df0c in GC_mark_some=20
> (cold_gc_frame=3D0x7fffffffc73c "") at ../mark.c:359
> #4  0x00007ffff7b853f8 in GC_stopped_mark=20
> (stop_func=3D0x7ffff7b846d0 <GC_never_stop_func>) at ../alloc.c:602
> #5  0x00007ffff7b8568d in GC_try_to_collect_inner=20
> (stop_func=3D0x7ffff7b846d0 <GC_never_stop_func>) at ../alloc.c:421
> #6  0x00007ffff7b905c2 in GC_init () at ../misc.c:843
> #7  0x0000000000400788 in main (argc=3D1, argv=3D0x7fffffffc8e8)=20
> at ,,t.c:6 --8<---------------cut=20
> here---------------end--------------->8---
>=20
> That's the 'stmxcsr' instruction, apparently an MMX2=20
> instruction, unconditionally used by the linux/x86_64=20
> getcontext(3) implementation.
>=20
> I find it surprising that getcontext(3) doesn't have a=20
> mechanism akin to '__x86_64_preferred_memory_instruction' to=20
> choose whether or not to use
> MMX2 instructions.
>=20
> Comments?
>=20
> Thanks,
> Ludo'.
>=20
> _______________________________________________
> Gc mailing list
> Gc-V9/[email protected]
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>=20