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

Hi,

ludo-mXXj517/[email protected] (Ludovic Court=C3=A8s) writes:

> Process record doesn't support instruction 0xf6e at address 0x7ffff789f=
2f2.
> Process record: failed to record execution log.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff789f2f0 in memset () from /nix/store/s88vdfglm94x7jn0vqm24pq=
hq460s0c7-glibc-2.9/lib/libc.so.6

I should have started with that: a web search shows that it=E2=80=99s a k=
nown
issue, not specific to libgc:

  http://sources.redhat.com/bugzilla/show_bug.cgi?id=3D10743
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D550710

The suggested workaround allows it to go a bit further:

--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=20
(gdb) n
warning: Process record ignores the memory change of instruction at addre=
ss 0x7ffff7612e5a because it can't get the value of the segment register.
warning: Process record ignores the memory change of instruction at addre=
ss 0x7ffff784e8c3 because it can't get the value of the segment register.
Process record doesn't support instruction 0xfae at address 0x7ffff7862c0=
0.
Process record: failed to record execution log.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7862c00 in getcontext () from /nix/store/s88vdfglm94x7jn0vqm24=
pqhq460s0c7-glibc-2.9/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7862c00 in getcontext () from /nix/store/s88vdfglm94x7jn0v=
qm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
#1  0x00007ffff7b96cfa in GC_with_callee_saves_pushed (fn=3D<value optimi=
zed out>, arg=3D0x7fffffffc73c "") at ../mach_dep.c:194
#2  0x00007ffff7b8e795 in GC_push_roots (all=3D<value optimized out>, col=
d_gc_frame=3D0x7fffffffc73c "") at ../mark_rts.c:790
#3  0x00007ffff7b8df0c in GC_mark_some (cold_gc_frame=3D0x7fffffffc73c ""=
) at ../mark.c:359
#4  0x00007ffff7b853f8 in GC_stopped_mark (stop_func=3D0x7ffff7b846d0 <GC=
_never_stop_func>) at ../alloc.c:602
#5  0x00007ffff7b8568d in GC_try_to_collect_inner (stop_func=3D0x7ffff7b8=
46d0 <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) at ,,t.c=
:6
--8<---------------cut here---------------end--------------->8---

That=E2=80=99s the =E2=80=98stmxcsr=E2=80=99 instruction, apparently an M=
MX2 instruction,
unconditionally used by the linux/x86_64 getcontext(3) implementation.

I find it surprising that getcontext(3) doesn=E2=80=99t have a mechanism =
akin to
=E2=80=98__x86_64_preferred_memory_instruction=E2=80=99 to choose whether=
 or not to use
MMX2 instructions.

Comments?

Thanks,
Ludo=E2=80=99.