From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25199 invoked by alias); 5 Jan 2012 19:54:17 -0000 Received: (qmail 25174 invoked by uid 22791); 5 Jan 2012 19:54:16 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 19:54:03 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 19:54:02 -0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com ([9.149.38.185]) by e06smtp12.uk.ibm.com ([192.168.101.142]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jan 2012 19:53:32 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05JrVwg2224148 for ; Thu, 5 Jan 2012 19:53:31 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05JrV3Y025093 for ; Thu, 5 Jan 2012 12:53:31 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q05JrUDS025048; Thu, 5 Jan 2012 12:53:30 -0700 Message-Id: <201201051953.q05JrUDS025048@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 05 Jan 2012 20:53:30 +0100 Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) To: alves.ped@gmail.com (Pedro Alves) Date: Thu, 05 Jan 2012 19:54:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com In-Reply-To: <4F05E9C8.9060706@gmail.com> from "Pedro Alves" at Jan 05, 2012 06:19:52 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010519-8372-0000-0000-0000014769F3 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 X-SW-Source: 2012-01/txt/msg00204.txt.bz2 Pedro Alves wrote: > On 01/05/2012 06:02 PM, Ulrich Weigand wrote: > > I'm wondering: How can I distinguish the "magic 42000" from > > a regular PID 42000 ? > > AFAIK, there's no such thing as a 42000 PID; PIDs on Linux are limited > to 16-bit. See my reply to Mark; this is no longer true in general these days. > > In particular, with Linux native targets, "pid" is what getpid () returns; > > "lwp" is the Linux task ID -- which is equal to the pid for single-threaded > > processes, and "tid" is the value of "pthread_t" for the thread. > > Ah. I see the confusion. That's no longer the case for a couple years. > We only store the LWP id in the ptid. The TID is always empty. We don't need > the pthread_id, given Linux's 1:1 thread model. Ah right, I missed that. > > Now, with the remote target, "pid" seems to be the magic 42000; "lwp" is > > never used, and "tid" is used for the thread ID used with the remote > > protocol -- and when using gdbserver, the latter is actually the LWP ID > > / Linux task ID. > > Right. So in reality, only ever one of the tid or the lwpid fields is > non-zero. And the one that is non-zero is the LWP id we want. Well, I guess one could implement some heuristics along those lines that do indeed work with Linux native and gdbserver targets. But this would still make a number of assumptions about how those fields are used -- which may be true at the moment, but not guaranteed. In particular, it seems to me that the remote protocol specification considers TID values to be defined by the remote side; the host side should only use them as identifiers without interpreting them. While gdbserver does use the LWPID here, I don't think it is guaranteed that other implementations of the remote protocol do the same, even on Linux targets (i.e. where linux-tdep files get used). So all in all, this still looks a violation of abstraction layers to me, which is the main reason why I advocated going back to the TARGET_OBJECT_PROC approach ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com