RE: Stopping reverse debugging behaves differently with btrace

["Metzger, Markus T" <markus dot t dot metzger at 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.

If I understand the code correctly, infrun's normal_stop calls a normal_stop
observer to which front-ends register.  The front-end is then responsible
for printing the current source location.  In the case of MI, this should also
give the stopped notification to GUIs.  I assume it's this notification you're
talking about.

We also shouldn't get a notification for the "record goto" command.  This
affects all record targets.  Historically, the "record goto" command does not call
the normal_stop observer and instead calls print_stack_frame directly.  Are you
seeing this, as well, Marc?


When I try to either call observer_notify_normal_stop (NULL, 1) directly or
indirectly via normal_stop, I get repeated breakpoint notifications for the
breakpoint at which the thread stopped originally.  Looking at those functions
I may get other notifications, as well, depending on global state.

It looks like the trick is to do what's normally done after target_wait.  I found
some code in infrun that seems to do something like that:

      /* Go through handle_inferior_event/normal_stop, so we always
	 have consistent output as if the stop event had been
	 reported.  */
      ecs->ptid = info->ptid;
      ecs->event_thread = info;
      ecs->ws.kind = TARGET_WAITKIND_STOPPED;
      ecs->ws.value.sig = GDB_SIGNAL_0;

      handle_inferior_event (ecs);

      if (!ecs->wait_some_more)
	{
	  /* Cancel any running execution command.  */
	  thread_cancel_execution_command (info);

	  normal_stop ();
	}


When I do that for "record goto" and "record stop" I get "Thread x stopped." as
well as "Switching to thread x" notifications.  I'm not sure if we want them.

Pedro, is this the right direction?  Would we need to go through the entire
proceed/resume/wait flow?  Or is the above already too complicated?

Thanks,
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