RE: Stopping reverse debugging behaves differently with btrace

["Metzger, Markus T" <markus dot t dot metzger at intel dot com>]

Hi Marc,

> > 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="/li
> b64/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.

Hmmm, the alternative would be to go through the full proceed/resume/
wait/normal_stop flow for "record goto".  This would give a ^running and a
prompt followed by a *stopped notification.  There's a problem with this,
though - see below.


> > 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.

OK, let's go without a stop reason for now.


> > 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",v
> alue="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",v
> alue="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
> 
> That also seems right.
> Eclipse does not yet support reverse debugging with non-stop, but we are
> working on it.

That's the output for stop-all.  On "record stop" GDB is iterating over all threads to
stop recording and I'm sending a notification for every thread that moved due to
this.

If we wanted a stepping-like behavior (as sketched above), GDB would report a
single event in stop-all mode and queue events of other threads to be reported
when they are resumed the next time.

That's not desirable since we would need multiple "continue" after "record stop"
to drain all those implicit record goto stopped events.

To the contrary, GDB implicitly stops replaying other threads if the selected thread
is resumed at the end of its execution history.  This is to avoid having to switch to
all replaying threads and do an explicit "record goto end".

Those implicit moves also do not trigger *stopped notifications.  I don't think they
should.  We're getting

    ^running
    *running,thread-id="all"

which already indicates that other threads may have moved, as well.

If we look at another command that affects multiple threads

    (gdb) 
    kill
    &"kill\n"
    =thread-exited,id="1",group-id="i1"
    =thread-exited,id="2",group-id="i1"
    =thread-group-exited,id="i1"
    ^done

I think that's what we'd want for "record stop" as well.  If *stopped doesn't
work, we may need a new record.

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