From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8426 invoked by alias); 6 Jan 2012 12:27:36 -0000 Received: (qmail 8413 invoked by uid 22791); 6 Jan 2012 12:27:33 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ee0-f41.google.com (HELO mail-ee0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 12:27:18 +0000 Received: by eekc41 with SMTP id c41so1109703eek.0 for ; Fri, 06 Jan 2012 04:27:17 -0800 (PST) Received: by 10.213.11.13 with SMTP id r13mr1205358ebr.119.1325852837445; Fri, 06 Jan 2012 04:27:17 -0800 (PST) Received: from [192.168.0.103] (bl21-184-26.dsl.telepac.pt. [2.82.184.26]) by mx.google.com with ESMTPS id t59sm247008989eeh.10.2012.01.06.04.27.15 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 04:27:16 -0800 (PST) Message-ID: <4F06E8A2.4090109@gmail.com> Date: Fri, 06 Jan 2012 12:27:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Ulrich Weigand CC: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) References: <201201051953.q05JrUDS025048@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201201051953.q05JrUDS025048@d06av02.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00234.txt.bz2 On 01/05/2012 07:53 PM, Ulrich Weigand wrote: > 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. Thanks. Always learning. However, the problem was knowing when 42000 was the magic PID, or when it was a real PID. That should not be a problem, because it is GDB itself that comes up with the 42000 magic number, not the server. It's just a GDB implementation detail. >> 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. Yes, that is true in general. > 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). ... however, let's revisit the problem with a fresh start. We have a command "info proc FOO PID", that accepts any target process ID, whose description is: (gdb) help info proc Show /proc process information about any running process. Specify any process id, or use the program being debugged by default. Let's ignore the "or use the program being debugged by default" part for now; it is a (big) convenience, and a separate problem, one of mapping the program being debugged to a process id. (The dropping of the support for specifying any process id in the proposed implementations seems more like accommodating the implementation, so let's step back on that too.) Now, we want to make this work on remote targets. For several reasons I've stated, I think this is best done with converting the always-host open/read/close's into remote target filesystem operations. To recap: - target objects aren't ideal for the case of reading files out of /proc for the case of reading them from random processes, not being debugged, that are currently running, because on the server side, you need to open/read/close the file descriptor at every partial transfer, which leads itself to corrupt transfers if the file changes between partial transfers, or, you need to cache the whole object (as we presently do for xml objects). The latter has the downside of needing to hold on to the object in memory on the server side, and to assume GDB always reads the object starting from offset 0. IMO, that's not a good assumption for binary objects. - A natural solution, is, IMO, realize we're already assuming a /proc target on the client (gdb) side, so the client might as well read the /proc files directly itself. After this, we're now left with the "or use the program being debugged by default" problem to solve. This has a use in more scenarios, so it's useful to state it as a problem in its own right. Off-hand examples are, I/T sets `p' prefix idea, and even remote core generation, so you can write the correct PID on the core file. So this sub-problem can be simply specified as: Given a gdb inferior or thread, return it's target process id. Now, we can come up with a new method to retrieve that info from the server. However, all the Linux targets I know about that have /proc contents access (gdbserver), have a 1:1 mapping in the RSP between RSP process, and target process, so we might as well start out with defaulting to assume that, and add such a mechanism when we find a need for it. IMO. > So all in all, this still looks a violation of abstraction layers > to me, So I see this as two distinct, but related problems. And when I look at the /proc retrieval part alone, I favor the remote filesystem access, as the most natural way to transparently make the command work with remote targets. And for cores too, as you yourself mentioned, the kernel can put /proc contents in cores, and, I could imagine taking a snapshot of /proc for the whole process tree (either above a given process (children, siblings, etc.), or starting at PID 1, and storing that in, or along the core, to be something useful. > which is the main reason why I advocated going back to the > TARGET_OBJECT_PROC approach ... If you're still not convinced, and others don't support my view, than I will step back and won't block your going forward with that. However, what did you think of my earlier comments regarding splitting that into separate objects?