This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 8/8] Special-case wildcard requests in ravenscar-thread.c


On 02/07/2019 09:40 AM, Tom Tromey wrote:
> From: Tom Tromey <tromey@adacore.com>
> 
> ravenscar-thread.c intercepts resume and wait target requests and
> replaces the requested ptid with the ptid of the underlying CPU.
> However, this is incorrect when a request is made with a wildcard
> ptid.

Can you clarify a bit more what went wrong?
IIRC, the base target always has one thread/cpu only, anyway?  What
difference does the patch make in practice?

The reason I'm wondering is because the patch makes me wonder about
a step request with no sched-lock, which is the default (*).
In that case, you'll have:

 - the thread to step is in inferior_ptid
 - ptid == minus_one_ptid (indicating everything resumes / no schedlock)

So seems like after this patch the lower layer might get a request to step
an unknown inferior_ptid?  Might not happen by luck/accident.
I'd suspect that you'd want to do instead:

  inferior_ptid = m_base_ptid;
  /* If we see a wildcard resume, we simply pass that on.  Otherwise,
     arrange to resume the base ptid.  */
  if (ptid != minus_one_ptid)
    ptid = m_base_ptid;
  beneath ()->resume (ptid, step, siggnal);

I.e., always flip inferior_ptid.

(*) since ravenscar-thread.c doesn't know how to interact with
    the ravenscar runtime to specify which threads are resumable,
    "schedlock on" most certainly doesn't work properly.  E.g.,
      "task 1 stops; set scheduler-locking on; task 2; step"
    seemingly will step task 1 instead of 2, AFAICT.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]