RE: Stopping reverse debugging behaves differently with btrace

[Marc Khouzam <marc dot khouzam at ericsson 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