This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Remove libthread_db -> remove thread_stratum? [was Re: Cannot execute this command without a live selected thread.]
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 13:52:06 -0700
- Subject: Remove libthread_db -> remove thread_stratum? [was 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>
[note subject change]
Doug Evans writes:
> 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.
>
> > 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]
Oh, btw, another question I've been wanting to ask ...
One goal we have is to remove libthread_db on linux.
There are two reasons we still have it, pthread_t and thread local vars,
though those can be solved.
Long term, at least in linux-land,
do we still want to keep thread_stratum?
Knowing the answer to this will help save some typing.
[If one did want to remove thread_stratum for linux
there's still a need to support older systems.
But on future newer systems without libthread_db,
what would thread_stratum look like?]