This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Cannot execute this command without a live selected thread.
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 23:06:59 +0100
- Subject: Re: Cannot execute this command without a live selected thread.
- Authentication-results: sourceware.org; auth=none
- References: <544A7648 dot 6060102 at codesourcery dot com> <544A7930 dot 4040909 at redhat dot com> <544A8741 dot 9090705 at codesourcery dot com> <544A8B0C dot 5000509 at redhat dot com> <544A8F15 dot 9000906 at redhat dot com> <21578 dot 42546 dot 658345 dot 633154 at ruffy dot mtv dot corp dot google dot com> <544AAB39 dot 4030503 at redhat dot com> <21578 dot 45122 dot 246973 dot 309386 at ruffy dot mtv dot corp dot google dot com> <544AB48A dot 9080503 at redhat dot com> <21578 dot 47311 dot 671976 dot 969985 at ruffy dot mtv dot corp dot google dot com>
On 10/24/2014 09:38 PM, Doug Evans wrote:
> Pedro Alves writes:
> > > Not all targets use ptid.lwp.
> >
> > All process_stratum targets do.
>
> windows-nat.c doesn't
> (at least I remember seeing all calls to ptid_build there
> passing 0 for lwp).
> Could be missing something of course.
Eh, I was quite sure I once wrote a patch for that, and
I thought I had pushed it, but I can't find it now.
Ah, back in 2008 I went through all targets migrating
away from storing the thread in ptid_t.pid.
commit 2dc38344f418c9abe65755308ef6db836a61103a
Author: Pedro Alves <palves@redhat.com>
Use ptid_t.tid to store thread ids instead of ptid_t.pid.
* win32-nat.c (win32_add_thread): Change thread argument type to
etc. That made way for the multi-process support in the core
being able to rely on ptid_t.pid.
It was much later (years) that I realized that ptid.lwpid would
be a better field.
Anyway, should be a trivial change. Nothing outside the target
should be looking at ptid.lwpid vs ptid.tid. I fixed gnu-nat.c
and remote.c recently, but I now see that nto-procfs.c, remote-sim.c
and darwin-nat.c still haven't been given the treatment.
I got confused with wishful thinking. :-P
>
> > I believe that on the GDB side too, it's best that we standardize on
> > process_stratum targets using the ptid.lwp field to store thread ids
> > anyway. The idea being leave the ptid.tid field free for any
> > thread_stratum target that might want to sit on top.
>
> The language in the comment in ptid.h waffles a bit:
>
> process_stratum targets that handle threading themselves should
> prefer using the ptid.lwp field, leaving the ptid.tid field for any
> thread_stratum target that might want to sit on top.
>
> Can we make this more of a rule than just a "should prefer"?
> [and fix targets to follow]
Sure, guess I didn't use a stronger word at the time because
I hadn't yet forgotten that the all-targets conversion wasn't
finished. :-)
Thanks,
Pedro Alves