Hi! On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu <hacklu.newb...@gmail.com> wrote: > On Fri, Sep 6, 2013 at 5:37 AM, Thomas Schwinge <tho...@codesourcery.com> > wrote: > >> (correct me if > >> I'm wrong here), the Hurd's threads are kernel threads > > > > Correct. > > > >> so it'd > >> be better to just make the GDB side use the lwp field too. > >> It's really a simple and mechanic change. Nothing in GDB core > >> actually cares which field is used. So in this case, it'd be
In GDB's parlance, a lightweight process (identified by a LWP) is a
thread that always has a corresponding kernel thread, and in contrast a
"generic" thread (identified by a TID) is not required to always have a
corresponding kernel thread, for example, when managed by a run-time
library? Then, yes, conceptually the native Hurd port should be switched
to using LWPs instead of TIDs.
> >> better if you send a preparatory patch
> >
> > Based on the current upstream master branch.
>
> Should I change the gdb use lwp filed instead of tid field? There are
> too many functions use tid. Like
> make_proc(),inf_tid_to_thread(),ptid_build(), and there is a field
> named tid in the structure proc also.
As you have found, there is a lot of TID usage in gnu-nat.c. TIDs are
assigned based on the next_thread_id variable:
/* A variable from which to assign new TIDs. */
static int next_thread_id = 1;
[...]
/* THREADS[I] is a thread we don't know about yet! */
{
ptid_t ptid;
thread = make_proc (inf, threads[i], next_thread_id++);
Five years ago, we've already concluded this is due for some cleanup,
<http://www.gnu.org/software/hurd/open_issues/gdb_thread_ids.html>. But
I don't want to require this cleanup to happen before/in context of the
Google Summer of Code project's code submission discussed here.
> We can define a macro for gdbserver to use another ptid_build function
> to use lwp instead of tid, if this, we only need do a little change.
That seems like a sensible approach to me, for the moment. And then do
the cleanup later on.
> Because of there are a lot of place to improve in my patch, I will
> submit my next patch a little later. Now I have only finished
> removing the spurious blank and the soft link.
That's fine. Such tasks always takes longer than expected. ;-)
Grüße,
Thomas
pgpE83ZxjK55L.pgp
Description: PGP signature
