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.

Eclipse Mars.2 seems to be OK with it.


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

Eclipse seems to be able to handle it but it may cause a thread switch.  Plus this
causes lots of output on the CLI.  I don't think we want that.

For stop-all mode, I changed this to send a single *stopped for the selected thread -
provided it is replaying.  This works fine as long as the selected thread actually is
replaying.  All threads are updated and we're not switching away from the selected
thread.

If the selected thread isn't replaying, however, GDB won't send a *stopped.  This is
OK for the selected thread as its state didn't change, but it won't cause other threads
that had been replaying to be updated.

I added another *stopped event without thread information for that case.  Eclipse
seems to be OK with it.  We're not switching threads but other threads seem to be
updated correctly.


I pushed the series into users/mmetzger/record-goto-mi.  Let me know what you think
and if this is working for you.  I will send the patches out for review in a week or two.

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