From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32734 invoked by alias); 11 Jan 2012 17:54:07 -0000 Received: (qmail 32722 invoked by uid 22791); 11 Jan 2012 17:54:05 -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 e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jan 2012 17:53:52 +0000 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Jan 2012 17:53:50 -0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com ([9.149.38.185]) by e06smtp11.uk.ibm.com ([192.168.101.141]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 11 Jan 2012 17:53:47 -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 q0BHrl7k1724608 for ; Wed, 11 Jan 2012 17:53:47 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 q0BHrkHt004603 for ; Wed, 11 Jan 2012 10:53:46 -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 q0BHrjaU004586; Wed, 11 Jan 2012 10:53:45 -0700 Message-Id: <201201111753.q0BHrjaU004586@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 11 Jan 2012 18:53:45 +0100 Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) To: palves@redhat.com (Pedro Alves) Date: Wed, 11 Jan 2012 18:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, sergiodj@redhat.com In-Reply-To: <4F0DB2F6.7050807@redhat.com> from "Pedro Alves" at Jan 11, 2012 04:04:06 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12011117-5024-0000-0000-0000015809BA 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/msg00359.txt.bz2 Pedro Alves wrote: > On 01/09/2012 03:43 PM, Ulrich Weigand wrote: > > - 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. > > Note that I'm not talking about the notion of a "process id" escape > escape to common/core code, but only to the linux gdbarch/osabi > specific bits; or other code that can deal with it, guarded by > "is there a notion of a process id on this target. Ah, I see. OK, I guess this make sense ... > > 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 ... > > As mentioned before, by broadcasting support for multi-process extensions > even with "target remote" (but don't allow debugging multiple processes), > and defaulting to assume a 1:1 mapping between target process id > and RSP process id, until some target needs to do something else, at > which point we define a new packet. OK, that was the piece I was missing. Yes, if we enable the multi-process extension, that should work. > I've spent a bit today prototyping /proc access this way the way > I was imagining it. See the attached patch series. This is far from > complete. It's just enough to get something working. Ah, thanks! I should have posted my work-in-progress patch series; I had already implemented most of what's in your patches, except for the process-id bits. Sorry for causing you extra work! So, both the features: - enable multi-process extension to get better PID - have an inferior flag to specify whether the PID is "fake" or corresponds to a target PID make sense to me, and looks like they should be enabled anyway. If we can then implement /proc access without any further protocol extension, I don't really have any objection ... I'll integrate your suggestions with my WIP patches and see how far I get. > > 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? > > - Decoupling of the objects in question from a "/proc" idea, so they > can be more generally used in other scenarios, like e.g., a remote > protocol implementation of target_pid_to_str (TARGET_OBJECT_PROC/exe). > - Let GDB have a finer grained idea of what subset of /proc-ish objects > are supported upfront (through qSupported), without any new mechanism. I still don't quite see why we cannot do the same with using the annex. In both cases, users in GDB would do some form of target_read and check the error code; the only difference is whether they use TARGET_OBJECT_PROC with a non-NULL annex, or else TARGET_OBJECT_PROC_xxx without annex. But I guess if we don't do TARGET_OBJECT_PROC at all it doesn't matter. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com