From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20584 invoked by alias); 18 Sep 2013 13:48:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20574 invoked by uid 89); 18 Sep 2013 13:48:52 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 18 Sep 2013 13:48:52 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GARBLED_BODY,KHOP_THREADED,NO_RELAYS autolearn=no version=3.3.2 X-HELO: mail-la0-f45.google.com Received: by mail-la0-f45.google.com with SMTP id eh20so5601590lab.4 for ; Wed, 18 Sep 2013 06:48:47 -0700 (PDT) X-Received: by 10.152.29.201 with SMTP id m9mr35317136lah.6.1379512127701; Wed, 18 Sep 2013 06:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.130.194 with HTTP; Wed, 18 Sep 2013 06:48:32 -0700 (PDT) In-Reply-To: <5239988F.6070600@redhat.com> References: <87txi2i6t6.fsf@kepler.schwinge.homeip.net> <5225C3C6.8090101@redhat.com> <5228DBA7.9050408@redhat.com> <87ob87c5lr.fsf@kepler.schwinge.homeip.net> <87bo42b9l7.fsf@kepler.schwinge.homeip.net> <5239988F.6070600@redhat.com> From: Yue Lu Date: Wed, 18 Sep 2013 13:48:00 -0000 Message-ID: Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd To: Pedro Alves Cc: Thomas Schwinge , gdb-patches , Luis Machado , bug-hurd@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00590.txt.bz2 Hi, On Wed, Sep 18, 2013 at 8:11 PM, Pedro Alves wrote: > On 09/09/2013 10:58 AM, Thomas Schwinge wrote: >> Hi! >> >> On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu wro= te: >>> On Fri, Sep 6, 2013 at 5:37 AM, Thomas Schwinge 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 =3D 1; >> [...] >> /* THREADS[I] is a thread we don't know about yet! */ >> { >> ptid_t ptid; >> >> thread =3D make_proc (inf, threads[i], next_thread_id++); >> >> Five years ago, we've already concluded this is due for some cleanup, >> . 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 =3D 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 =3D 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)); --=20 Yue Lu (=E9=99=86=E5=B2=B3)