From: Yue Lu <hacklu.newborn@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
gdb-patches <gdb-patches@sourceware.org>,
Luis Machado <lgustavo@codesourcery.com>,
bug-hurd@gnu.org
Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd
Date: Wed, 18 Sep 2013 13:48:00 -0000 [thread overview]
Message-ID: <CAB8fV=iXihaZEmppJ9GMuRrtnhC11--8bnfJek9FrDnZNNDzSQ@mail.gmail.com> (raw)
In-Reply-To: <5239988F.6070600@redhat.com>
Hi,
On Wed, Sep 18, 2013 at 8:11 PM, Pedro Alves <palves@redhat.com> wrote:
> On 09/09/2013 10:58 AM, Thomas Schwinge wrote:
>> 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.
>
> That's not what I'm suggesting at all. I'm just talking about storing
> the thread id in the lwpid field. It's always the target that
> stores and extracts the fields of a ptid -- the ptid_t struct is mostly
> opaque to the core. It should really be a small change.
>
> (while looking at this, I noticed a bug, and fixed it:
> http://sourceware.org/ml/gdb-patches/2013-09/msg00579.html)
>
> /me gives it a try.
>
> I grepped for ptid_build and ptid_get_tid in *gnu* files, and
> adjusted all I found.
I have tried this way before, but it doesn't work.
After apply your patch, the gdb can't use, it says "Can't fetch
registers from thread Thread 29826.3: No such thread". (btw, with
unknown reason, I can't patch your patch automatically, I have to
modify the gnu-nat.c line by line according to your patch).
As before, I thought it is a big problem, so I don't dig into it. Your
last email has reminder me, both you and I forgot to patch the
i386gnu-nat.c which also used the tid filed.
Add this everything is ok.
diff --git a/gdb/i386gnu-nat.c b/gdb/i386gnu-nat.c
index 0fd8d91..2b93fee 100644
--- a/gdb/i386gnu-nat.c
+++ b/gdb/i386gnu-nat.c
@@ -132,7 +132,7 @@ gnu_fetch_registers (struct target_ops *ops,
inf_update_procs (gnu_current_inf);
thread = inf_tid_to_thread (gnu_current_inf,
- ptid_get_tid (inferior_ptid));
+ ptid_get_lwp (inferior_ptid));
if (!thread)
error (_("Can't fetch registers from thread %s: No such thread"),
target_pid_to_str (inferior_ptid));
@@ -225,7 +225,7 @@ gnu_store_registers (struct target_ops *ops,
inf_update_procs (gnu_current_inf);
thread = inf_tid_to_thread (gnu_current_inf,
- ptid_get_tid (inferior_ptid));
+ ptid_get_lwp (inferior_ptid));
if (!thread)
error (_("Couldn't store registers into thread %s: No such thread"),
target_pid_to_str (inferior_ptid));
--
Yue Lu (陆岳)
next prev parent reply other threads:[~2013-09-18 13:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAB8fV=jJ64i91VW52ZmdnEDZhd1ZGTAykDqoFyPJanCP=5beqA@mail.gmail.com>
2013-09-03 8:03 ` [PATCH 2/2] " Yue Lu
2013-09-03 9:38 ` [PATCH 1/2] " Thomas Schwinge
2013-09-03 11:11 ` Pedro Alves
2013-09-03 13:09 ` Thomas Schwinge
2013-09-04 1:47 ` Yue Lu
2013-09-04 1:38 ` Yue Lu
2013-09-05 10:54 ` Yue Lu
2013-09-05 19:29 ` Pedro Alves
2013-09-05 19:39 ` Joel Brobecker
2013-09-05 21:38 ` Thomas Schwinge
2013-09-08 13:35 ` Yue Lu
2013-09-09 9:58 ` Thomas Schwinge
2013-09-18 12:12 ` Pedro Alves
2013-09-18 13:48 ` Yue Lu [this message]
2013-09-18 14:52 ` [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 14:57 ` [PATCH 1/2] Port gdbserver to GNU/Hurd Pedro Alves
2013-09-22 12:58 ` Yue Lu
2013-09-06 18:53 ` Pedro Alves
2013-09-12 3:05 ` Yue Lu
2013-09-18 12:30 ` Pedro Alves
2013-09-18 12:37 ` Pedro Alves
2013-09-19 7:41 ` Yue Lu
2013-09-19 8:30 ` FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited) (was: [PATCH 1/2] Port gdbserver to GNU/Hurd) Thomas Schwinge
2013-09-19 8:44 ` FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited) Pedro Alves
2013-09-09 10:21 ` [PATCH 1/2] Port gdbserver to GNU/Hurd Yue Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB8fV=iXihaZEmppJ9GMuRrtnhC11--8bnfJek9FrDnZNNDzSQ@mail.gmail.com' \
--to=hacklu.newborn@gmail.com \
--cc=bug-hurd@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=palves@redhat.com \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox