[PATCH 17/17] infrun: scheduler-locking reverse
Metzger, Markus T
markus.t.metzger@intel.com
Wed Sep 16 07:59:00 GMT 2015
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Jan Kratochvil
> Sent: Tuesday, September 15, 2015 7:20 PM
Hello Jan,
> On Tue, 15 Sep 2015 11:28:36 +0200, Metzger, Markus T wrote:
> > > Thanks for bringing it up. I would have hard time mergin this patch's:
> > > -static const char *scheduler_mode = schedlock_off;
> > > +static const char *scheduler_mode = schedlock_reverse;
> > > with
> > > http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.6-
> scheduler_locking-
> > > step-is-default.patch
> > > -static const char *scheduler_mode = schedlock_off;
> > > +static const char *scheduler_mode = schedlock_step;
> >
> > I don't believe that we need to preserve the current behaviour. If Fedora
> > defaults to schedlock_step, why not also for record targets?
>
> Yes, I would find logical that during "reverse-step" on Fedora the scheduler
> locking is also turned on. But I do not see how to achieve it with your
> patch. If I put there:
> static const char *scheduler_mode = schedlock_step;
> then during "reverse-*" commands there will be no scheduler locking.
That's a bug.
Record btrace still has some code that implements an implicit scheduler-
locking on during reverse/replay execution for all-stop targets. With Pedro's
ASNS patch, scheduler-locking should be honoured.
We could also make record btrace honour scheduler-locking for (soon legacy) all-
stop targets. The current implementation applies the same stepping command
to all threads matching the argument PTID:
ALL_NON_EXITED_THREADS (tp)
if (ptid_match (tp->ptid, ptid))
record_btrace_resume_thread (tp, flag);
I think what we want instead is to apply the requested stepping command to
INFERIOR_PTID and the corresponding continue command to all other threads
matching PTID. Is that correct?
We wouldn't even need to check for non-stop mode or distinguish between
non-stop and all-stop targets. Infrun should take care of all that.
What if INFERIOR_PTID does not match the argument PTID? Is that an internal
error? Or would we only resume the argument PTID in this case? What if it is
a process and not a single thread?
Record full doesn't really support multi-threading so scheduler-locking doesn't
apply.
> > The same holds for mainline, of course. But the new mode is much closer
> to
> > schedlock_step than it is to schedlock_off.
>
> Maybe. But when I make the default "schedlock_reverse" then it will
> regress
> Fedora's forward "step".
Mainline will default to schedlock_reverse to maintain the current behaviour.
Fedora will continue to default to schedlock_step and record btrace will now
behave correctly on (reverse-)continue commands (the current series doesn't
since the underlying target is still all-stop). It should already do the right thing
for (reverse-)step/next/finish commands.
> > I really only added the new mode because I did not want to change the
> default
> > behaviour completely. Over time, I think we may want to deprecate it,
> even
> > though schedlock_off isn't very useful with the usually quite short
> execution
> > history. Maybe mainline will default to schedlock_step one day, as well?
>
> But how to make the schedlock_step default while still benefiting from your
> patch?
The goal is to have record btrace honour scheduler-locking. This patch is trying
to do this without changing the current default behaviour by making the current
behaviour a new scheduler-locking mode.
> If I/we make schedlock_step the default then this code of your patch gets
> disabled:
>
> + else if ((scheduler_mode == schedlock_reverse)
> + && ((execution_direction == EXEC_REVERSE)
> + || target_record_is_replaying (minus_one_ptid)))
> + {
> + /* User-settable 'scheduler' mode requires solo thread resume during
> + reverse/replay stepping. */
> + resume_ptid = inferior_ptid;
> + }
Yes. But the code above this in infrun.c then applies:
else if ((scheduler_mode == schedlock_on)
|| (scheduler_mode == schedlock_step && step))
{
/* User-settable 'scheduler' mode requires solo thread
resume. */
resume_ptid = inferior_ptid;
}
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
More information about the Gdb-patches
mailing list