This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Stopping reverse debugging behaves differently with btrace
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Marc Khouzam <marc dot khouzam at ericsson dot com>, "Pedro Alves (palves at redhat dot com)" <palves at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 13 Jun 2016 15:21:38 +0000
- Subject: RE: Stopping reverse debugging behaves differently with btrace
- Authentication-results: sourceware.org; auth=none
- References: <E59706EF8DB1D147B15BECA3322E4BDC22ABACFE at eusaamb103 dot ericsson dot se> <A78C989F6D9628469189715575E55B23332EBBB8 at IRSMSX104 dot ger dot corp dot intel dot com> <A78C989F6D9628469189715575E55B23332EC30D at IRSMSX104 dot ger dot corp dot intel dot com>
Hi Marc, Pedro,
> > > I find it strange though that when turning off record, every indication
> > > to the user is that we are still at line 150, when in reality, GDB is
> > > effectively back at line 200. This is particularly noticeable in a
> > > frontends when execution jumps (unexpectedly) when the first step
> > > is requested.
> > >
> > > Variables also remain unavailable until the next step (or strangely,
> > > until I send some register command).
> > >
> > > I was wondering if GDB should reset its execution to the proper
> > > place upon a 'record stop' for btrace? And notify the frontend of
> > > that change.
> >
> > I agree. I'll look into it. Thanks for pointing it out.
>
> I have a fix for the missing STOP_PC update which may result in all
> kinds of strange effects. The front-end notification sounds more
> tricky, though.
Looks like the trick is to clear the proceed state of the moving thread
before calling the normal-stop observer. I'm omitting the about-to-
proceed notification and I'm not calling proceed or normal_stop.
I hope I'm not breaking something.
GDB is now sending a normal-stop without stop reason on every record
goto command:
(gdb)
rec go 12
&"rec go 12\n"
~"0x00007ffff762c671 in _dl_addr () from /lib64/libc.so.6\n"
*stopped,frame={addr="0x00007ffff762c671",func="_dl_addr",args=[],from="/lib64/libc.so.6"},thread-id="1",stopped-threads="all",core="1"
^done
We can also invent a new stop-reason if necessary. The record-btrace
target also sends such a normal-stop notification on "record stop" for
each replaying thread:
(gdb)
rec stop
&"rec stop\n"
~"test (arg=0x0) at gdb.btrace/multi-thread-step.c:34\n"
~"34\t global = 42; /* bp.2 */\n"
*stopped,frame={addr="0x000000000040078a",func="test",args=[{name="arg",value="0x0"}],file="gdb.btrace/multi-thread-step.c",fullname="gdb.btrace/multi-thread-step.c",line="34"},thread-id="1",stopped-threads="all",core="1"
~"test (arg=0x0) at gdb.btrace/multi-thread-step.c:34\n"
~"34\t global = 42; /* bp.2 */\n"
*stopped,frame={addr="0x000000000040078a",func="test",args=[{name="arg",value="0x0"}],file="gdb.btrace/multi-thread-step.c",fullname="gdb.btrace/multi-thread-step.c",line="34"},thread-id="2",stopped-threads="all",core="1"
~"Process record is stopped and all execution logs are deleted.\n"
=record-stopped,thread-group="i1"
^done
Marc, is this what you were expecting?
The CLI output for "record stop" needs more polishing. It currently prints the
updated source location for every replaying thread without indicating the thread
the output belongs to. Not sure how much output we really want on the CLI for
"record stop".
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928