From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22390 invoked by alias); 9 Sep 2013 09:58:27 -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 22379 invoked by uid 89); 9 Sep 2013 09:58:26 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2013 09:58:26 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VIyEe-00024a-Fu from Thomas_Schwinge@mentor.com ; Mon, 09 Sep 2013 02:58:20 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Sep 2013 02:58:20 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 9 Sep 2013 10:58:18 +0100 From: Thomas Schwinge To: Yue Lu , Pedro Alves CC: gdb-patches , Luis Machado , Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd In-Reply-To: References: <87txi2i6t6.fsf@kepler.schwinge.homeip.net> <5225C3C6.8090101@redhat.com> <5228DBA7.9050408@redhat.com> <87ob87c5lr.fsf@kepler.schwinge.homeip.net> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) Date: Mon, 09 Sep 2013 09:58:00 -0000 Message-ID: <87bo42b9l7.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2013-09/txt/msg00276.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2404 Hi! On Sun, 8 Sep 2013 21:35:05 +0800, Yue Lu wrote: > 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. >=20 > 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; =20=20=20=20 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. > 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=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSLZu0AAoJEGe3hdm9kOiiqBIIAKI6+7u4uVa5qSTnyJo8cHVb cLrXN+ecNwd/s8zmU+1zi4e3ujtOvopt3d4LeVei+GSSgC/AmcoxsOmS3KZs4vmu hEujjd96rRMepyccjZ0xfoTxwbDf/Kmid7YCXivhny0D2QxbRyiauc/bh1Ccg06A ih8HlkNdMjUT+VLSXatY+UA8w6O5iKUGw6fkVKgPbjLuPOjsLLEUi1J5VEM/szyi jeo80cv/fAKEz3jV+Cd8fezRPGxgEEsIvFAErQkvNkQB+879tsmQ1TUqN4i1RO39 vF4OI4k28AD084mU/AFJFpfXCi+bk8udA86o5gfyc6mOlB7nBVehXuHcbmUjCtg= =u7nt -----END PGP SIGNATURE----- --=-=-=--