Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Hi!

On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu <hacklu.newborn@gmail.com> wrote:
> On Fri, Sep 6, 2013 at 5:37 AM, Thomas Schwinge <thomas@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

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]