From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14109 invoked by alias); 9 Jan 2012 15:44:12 -0000 Received: (qmail 14097 invoked by uid 22791); 9 Jan 2012 15:44:10 -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 e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Jan 2012 15:43:55 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jan 2012 15:43:53 -0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp13.uk.ibm.com ([192.168.101.143]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 9 Jan 2012 15:43:51 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q09Fhpjm2633978 for ; Mon, 9 Jan 2012 15:43:51 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 q09Fho7f024042 for ; Mon, 9 Jan 2012 08:43:50 -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 q09FhnrG024010; Mon, 9 Jan 2012 08:43:49 -0700 Message-Id: <201201091543.q09FhnrG024010@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 09 Jan 2012 16:43:49 +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: Mon, 09 Jan 2012 15:44:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com In-Reply-To: <4F06E8A2.4090109@gmail.com> from "Pedro Alves" at Jan 06, 2012 12:27:14 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010915-2966-0000-0000-000002D4944A 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/msg00272.txt.bz2 Pedro Alves wrote: > On 01/05/2012 07:53 PM, Ulrich Weigand wrote: > > 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.) It seems to me we're getting to the core of the problem here. For the existing "info proc" command, it indeed makes sense to talk about "process IDs", *because* the command is specific to a (native) target that supports processes and uses process IDs. Except for this, common GDB user interface commands do not currently refer to "process IDs"; while GDB obviously used "ptid_t" internally, it is *interpreted* only by target code, common code at most uses it for comparions (is this the same process as another one). [ The one obvious exception is the "attach" command which also takes a process ID. However, this is arguably also a target-specific command, in that the generic implementation quickly calls through to target code that implements the operation, starting with *parsing the argument*. ] Instead of refering to process IDs, GDB commands usually operate on the "current inferior", or else take GDB inferior (or thread) IDs as argument, which have no direct connection to the underlying OS process IDs. It seems to me this was a deliberate decision to try and isolate the common GDB code and user interfaces from OS implementation details: GDB is supposed to work just the same on targets where there are no processes, or where they are identified by different means that just an integer ID. Now, given the "anomaly" of the "info proc" command as is, I guess there's two ways to look at how to move forward: - We could say the anomaly was a mistake that we want to get rid of. In this view, it naturally follows that we remove the PID argument option and have the command operate on the "current inferior" as all other commands. This also makes an underlying interface that would retrieve proc file content of the current inferior natural. (This is what my patch set has implemented.) - We say instead that, yes, we *want* OS PIDs to be used as first- class user interface elements. But this means to me that we need to more generally make OS PIDs present in GDB common code so that common code is at least able to associate its internal notions of "inferior" with those IDs. At a minimum, this would imply we no longer consider "ptid_t" values to be opaque to GDB common code, but rather enforce that they agree with user- visible OS PID values. Now, I'm not necessarily opposed to the second approach, I'm just not sure I see all the consequences ... At a minimum, the use of the "magic 42000" becomes problematic if there is any chance the ptid_t gets exposed to the user at any point. > 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. I don't quite understand what you mean here. Could you elaborate how you propose to implement this routine "return the target process ID of a given GDB inferior/thread" without remote interface changes? This was exactly the "magic 42000" problem I was running into ... > > 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. I could imaging a core file of a process containing snapshots of /proc files *for that process*. It would seem rather odd to me to have /proc files of *other* processes as part of a core file. But that's certainly a side discussion ... > > 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? I must admit I don't see what the benefit of this is supposed to be. This seems to me to be the exact use case that "annex" is there to cover: a bunch of information with related content semantics, which are all accessed the same way, and the exact set is somewhat dynamic. Not using the annex would mean defining a whole bunch of new packet types, duplicated boilerplate code in GDB and gdbserver to hook them up, and then still the drawback that every new /proc file that may come up in the future will require extra code (including new gdbserver-side code!) to support. And for all those drawbacks, I don't see any single benefit ... Maybe you can elaborate? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com