RE: [PATCH v2 17/17] infrun: scheduler-locking reverse

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Wednesday, September 16, 2015 3:33 PM
> To: Metzger, Markus T; Eli Zaretskii
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse


> Actually, there's still one detail, that goes back to what I first asked;
> whether we call reverse execution "replay" too.  So it now
> sounds clearer to me that when we're reverse debugging with a target
> that does native reverse-stepping, where the user is not using
> a record/replay target and has not typed "record", etc., we don't
> call reverse debugging "replay".  However, the patch had this:
> 
> +  else if ((scheduler_mode == schedlock_reverse)
> +	   && ((execution_direction == EXEC_REVERSE)
> +	       || target_record_is_replaying (minus_one_ptid)))
> +    {

The target_record_is_replaying (minus_one_ptid) call checks whether
	a) there is a record target and
	b) whether at least one thread is in replay mode.

We might have a record target but none of the threads are currently
replaying.  For record btrace this means that all threads are at the end
of their execution history (including an empty history).

That's why we need to check the execution direction, as well.


> That means that the setting is in effect also when reverse debugging
> _without_ a record/replay target, e.g., with qemu/simics/etc.
> Do we want the setting to take effect with these too, or do we not?
> It doesn't a difference in practice today because the RSP packets for
> reverse debugging assuming a single threaded target, but once we
> support connecting to multiple remote targets at the same time, for
> instance, it would come into effect.

What if we added an execution_direction parameter to
to_record_is_replaying?

I wouldn't use the global variable since it isn't obvious that the execution
mode plays any role here.  It might further change between the check
and the actual resume.

Record btrace would return true if at least one thread is replaying or
if the execution direction is reverse.

Record full would return true if either
a) the execution direction is reverse and at least one thread is not
at the beginning of its execution history.
b) the execution direction is forward and at least one thread is not
at the end of its execution history.

That is, it will, once it actually supports this.

The default would be false.


If you're OK with this, I can add it as a separate patch and use it in the
schedlock patch.

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, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928