From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20782 invoked by alias); 5 Dec 2011 14:52:43 -0000 Received: (qmail 20727 invoked by uid 22791); 5 Dec 2011 14:52:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,TW_OC X-Spam-Check-By: sourceware.org Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Dec 2011 14:52:15 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Dec 2011 14:52:10 -0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com ([9.149.38.129]) by e06smtp10.uk.ibm.com ([192.168.101.140]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 5 Dec 2011 14:52:07 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB5Eq6JB2281568 for ; Mon, 5 Dec 2011 14:52:06 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 pB5Eq6VY009214 for ; Mon, 5 Dec 2011 07:52:06 -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 pB5Eq47S009157; Mon, 5 Dec 2011 07:52:05 -0700 Message-Id: <201112051452.pB5Eq47S009157@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 05 Dec 2011 15:52:04 +0100 Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) To: pedro@codesourcery.com (Pedro Alves) Date: Mon, 05 Dec 2011 15:02:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com In-Reply-To: <201112051247.59967.pedro@codesourcery.com> from "Pedro Alves" at Dec 05, 2011 12:47:59 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 11120514-4966-0000-0000-000000C0C4E5 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: 2011-12/txt/msg00141.txt.bz2 Pedro Alves wrote: > Hi Ulrich, sorry for the delay. I haven't managed to read your patches yet. > I'll reaply here first. Thanks for your comments! > First, the reason Sergio added "info mappings" instead of making > "info proc mappings" work for core files, was that using "info proc" > for cores was objected. I'm personally okay with it, but I think > that should be understood as not being a limitation of the design. Actually, Sergio's latest patches added "info core" with a number of subcommands, including "info core mappings". I didn't really like this. IMO the underlying problem with "info proc" is that it is a target-specific command in the first place. If you want to look at a process' memory map, you don't really care whether the process is running natively, or running on a remote machine accesses via gdbserver, or even if you're just looking at a core file. As a user, I don't really see why looking at the memory map should require use of different commands depending on the particular mode of operation, or even why it shouldn't work at all in some of those modes. "info proc" doesn't work that way; it is completely tied to native operation. Adding an "info core" does make some information available for core files, but it doesn't really solve the underlying problem: you still need to remember to use a different command, and even so it doesn't work for remote/gdbserver targets at all. That's why my suggestion was to instead move "info proc" to be target-independent. That is to say, it would still show Linux-specific information about a process, but it would no longer depend on whether you look at that Linux process natively, remotely, or post-mortem. (Of course in the core file case, that goal can only reached approximately, since some information is simply not available -- but that situation also applies in some other aspects to core files ...) Now, instead of this change to "info proc", we could add a new "info mappings" command. (Note that this would correspond to the "option 1" in my email.) This would have the same advantage of providing the same command for all modes of operation, and could actually be even more general, beyond just Linux targets, to cover any target that has a notion of memory-mapping files. However, at least in my opinion, this option still has drawbacks: Users today are used to "info proc mappings". Should we remove that command? Or else forward it to the new "info mappings"? But in either case there is now a disconnect to the other "info proc" commands; why should "info proc mappings" work on remote/gdbserver, but not the other commands? In the end, this still doesn't solve the fundamental problem of having a native-target-implemented command "info proc". > I have to say that I have reservations on this new TARGET_OBJECT_PROC > option. It adds yet another generic abstraction (it almost looks like > TARGET_OBJECT_OSDATA reinvented), yet the data it sends over is not > really structured. This maps nicely on linux, but, e.g, on procfs targets, > you have a bunch of different /proc implementations, it can actually be > awkward, in that you may need to translate whatever the real /proc/pid/foo > gives you into a format gdb expects. The answer to that seems to be that GDB > will install a gdbarch handler for each OS that understands > /proc/pid/foo for the target OS, but that means that either or both of core > gdb and the target (can result in weird wrong turns, if we add coping to > both ends) will have to keep up with whatever format changes happen > between OS revisions on the target side instead of being given a > structured, abstracted and simplified view (that could in turn be easily > marshalled in structured form to MI or python, if so desired). And then > there's no default gdb-side gdbarch implementation, so GDB needs to be > aware of the random embedded OSs to be able to support "info proc foo". > A structured format means that its definitely the target that gets to keep up. Well, IMO there's two "flavours" of target objects, if you will. Some objects are completely generic, fully defined by GDB -usually via XML-, and implemented (or implementable) across all target machines and operating systems. But there is another class of target objects whose contents are not generic, but specific to a particular architecture and/or operating system; they are still implemented as target object in order to give architecture code a way to get at those contents in a homogeneous way no matter whether GDB operates in native, remote, or core file mode. This class includes things like TARGET_OBJECT_SPU, TARGET_OBJECT_WCOOKIE, TARGET_OBJECT_DARWIN_DYLD_INFO, and probably something like the new TARGET_OBJECT_LIBRARIES_SVR4 ... In my mind, the proposed TARGET_OBJECT_PROC would fall into the second category, that is, it provides access to pre-existing, operating-system defined contents, while simply abstracting the means of delivery. In particular, I would not expect the "provider side" (Linux native target or gdbserver code) to ever implement any sort of "conversion" of the contents. If there ever should be changes to the contents of /proc files, the task of adapting to those changes should lie solely on the gdbarch code that consumes the TARGET_OBJECT_PROC objects. Of course, as you say, this means that TARGET_OBJECT_PROC really only can ever be consumed by OS-specific, usually gdbarch code. (But that's still better than having *native-target-only* code IMO.) I wouldn't mind renaming the object to TARGET_OBJECT_LINUX_PROC to make the intention about the objects contents clearer. (I thought that maybe other procfs targets could also use TARGET_OBJECT_PROC, but since of course the contents would be different, it might be better to use a new object type if and when we ever do that ...) > This is not a NAK, but I'm just saying I'm not fully convinced yet. Did this help convince you? :-) B.t.w. for the purpose I'm immediately interested in myself right now, which is to provide for remote/gdbserver core file generation, either my "option 1" via TARGET_OBJECT_ADDRESS_MAP or my "option 2" via TARGET_OBJECT_PROC would work just as well, and I've already implemented code for either ... So I'm not really very tied to TARGET_OBJECT_PROC; I've just come to thinking this would be the more general solution by getting rid of the native-target-implemented "info proc". Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com