[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd
Date: Mon, 9 Sep 2013 11:58:12 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


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.  ;-)


Attachment: pgplG0J8zGwZg.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]