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: Marc Khouzam <marc dot khouzam at ericsson dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel 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 17:43:41 +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>,<A78C989F6D9628469189715575E55B23332ED1C5 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
I'd have to try it to be sure, but this looks right. If a record command
changes the line at which GDB is stopped, the frontend needs a *stopped
event like that. Sending multiple *stopped events for the same thread without
a *running event in between may be a new case; I don't know if that is something
frontends are supposed to be ready for. I'm almost certain Eclipse can handle
it though.
> We can also invent a new stop-reason if necessary.
That is probably a nice clarification for the frontend.
However, looking at how Eclipse handles the 'reason' field, we are not ready
for a new one and will ignore any message with an unexpected 'reason'.
Again, I'd have to try it to be sure. It would be easy to fix and I would make
Eclipse accept any unkown reason as a generic *stopped event, but older
versions of Eclipse won't have that fix.
Please keep me in the loop about such a change.
> 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?
That also seems right.
Eclipse does not yet support reverse debugging with non-stop, but we are
working on it.
> 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.
Thanks for looking into this so quickly.
Marc