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

I couldn't immediately find much of a description of how the record mecha=
nism works.  Does it just interpret or single-step, recording overwritten=
 values?  Something cleverer?  Even if it just interprets, presumably I e=
nd up with a separate log for each thread.  If I can reverse-single-step =
thread individually, how do I make sure that I don't end up in an impossi=
ble state, in which one thread has observed the action of another one tha=
t hasn't executed yet?

I'm really trying to understand what part of the mechanism the GC might b=
e interfering with.  The GC itself doesn't play with segment registers.  =
But it does use thread-local variables by default, which I think on X86 t=
ake advantage of a segment register pointing at the base of the thread st=
ructure.  Is there a chance that the problem is really with thread-local =
(__thread) variables?

Hans

> -----Original Message-----
> From: gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/[email protected]=20
> [mailto:gc-bounces-o/PNRNCSakrWxDs0y9d3MAC/[email protected]] On Behalf Of Ludovic Court=E8s
> Sent: Tuesday, October 27, 2009 2:52 PM
> To: gc-o/PNRNCSakrWxDs0y9d3MAC/[email protected]
> Cc: bug-gdb-mXXj517/[email protected]
> Subject: [Gc] GDB 7's process record/replay & BDW-GC
>=20
> Hello,
>=20
> GDB 7.0 provides process record/replay facilities, which in=20
> turn provide support for reverse execution[*] (info "(gdb)=20
> Process Record and Replay").
>=20
> Unfortunately, GDB's record facility is confused by libgc's tricks:
>=20
> --8<---------------cut here---------------start------------->8---
> $ cat > ,,t.c <<EOF
> #include <gc/gc.h>
>=20
> int  =20
> main (int argc, char *argv[])
> {
>   GC_INIT ();
>   GC_malloc (123);
>   return 0;
> }
> EOF
>=20
> $ gcc -Wall ,,t.c -lgc
> $ gdb ./a.out=20
>=20
> warning: Can not parse XML syscalls information; XML support=20
> was disabled at compile time.
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later=20
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type=20
> "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/ludo/src/guile/a.out...done.
> (gdb) r
> Starting program: /home/ludo/src/guile/a.out [Thread=20
> debugging using libthread_db enabled]
>=20
> Program exited normally.
> (gdb) b main
> Breakpoint 1 at 0x400783: file ,,t.c, line 6.
> (gdb) r
> Starting program: /home/ludo/src/guile/a.out [Thread=20
> debugging using libthread_db enabled]
>=20
> Breakpoint 1, main (argc=3D1, argv=3D0x7fffffffc8e8) at ,,t.c:6
> 6         GC_INIT ();
> (gdb) record
> (gdb) c
> Continuing.
> 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 0xf6e at address=20
> 0x7ffff789f2f2.
> Process record: failed to record execution log.
>=20
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff789f2f0 in memset () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> (gdb) bt
> #0  0x00007ffff789f2f0 in memset () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> #1  0x00007ffff7b8a7c8 in GC_init_headers () at ../headers.c:197
> #2  0x00007ffff7b904cb in GC_init () at ../misc.c:788
> #3  0x0000000000400788 in main (argc=3D1, argv=3D0x7fffffffc8e8)=20
> at ,,t.c:6
> (gdb) c
> Continuing.
> Process record doesn't support instruction 0xf6e at address=20
> 0x7ffff789f2f2.
> Process record: failed to record execution log.
>=20
> Program received signal SIGABRT, Aborted.
> 0x00007ffff789f2f0 in memset () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> (gdb) bt
> #0  0x00007ffff789f2f0 in memset () from=20
> /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6
> #1  0x00007ffff7b8a7c8 in GC_init_headers () at ../headers.c:197
> #2  0x00007ffff7b904cb in GC_init () at ../misc.c:788
> #3  0x0000000000400788 in main (argc=3D1, argv=3D0x7fffffffc8e8)=20
> at ,,t.c:6 --8<---------------cut=20
> here---------------end--------------->8---
>=20
> Is it a known issue?  Any idea how to fix it?
>=20
> Thanks,
> Ludo'.
>=20
> [*] The 'multi-thread' target doesn't support reverse=20
> execution, but the
>     'record' target does.  Thus 'record' is the only way to=20
> get reverse
>     execution for multi-threaded programs.
>=20
> _______________________________________________
> Gc mailing list
> Gc-V9/[email protected]
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>=20