From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24795 invoked by alias); 5 Dec 2011 12:48:25 -0000 Received: (qmail 24786 invoked by uid 22791); 5 Dec 2011 12:48:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_OC X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Dec 2011 12:48:04 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RXXxj-0007MR-G6 from pedro_alves@mentor.com ; Mon, 05 Dec 2011 04:48:03 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Dec 2011 12:48:01 +0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) Date: Mon, 05 Dec 2011 12:59:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.7.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com References: <201111231632.pANGW8Ln008085@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201111231632.pANGW8Ln008085@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112051247.59967.pedro@codesourcery.com> 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: 2011-12/txt/msg00131.txt.bz2 Hi Ulrich, sorry for the delay. I haven't managed to read your patches yet. I'll reaply here first. On Wednesday 23 November 2011 16:32:08, Ulrich Weigand wrote: > I'd really appreciate thoughts / suggestions on whether the above > drawbacks are acceptable, and which option we should proceed with. 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. 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. This is not a NAK, but I'm just saying I'm not fully convinced yet. -- Pedro Alves