[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) |
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
pgplG0J8zGwZg.pgp
Description: PGP signature
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, (continued)
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Thomas Schwinge, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Joel Brobecker, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Thomas Schwinge, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/08
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd,
Thomas Schwinge <=
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/18
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/18
- [Hurd/gnu-nat.c] Use ptid_t.lwpid to store, thread ids instead of ptid_t.tid. (was: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd), Pedro Alves, 2013/09/18
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/18
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/22
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/06
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/11
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/18
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/18
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/19