From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18950 invoked by alias); 5 Jan 2012 16:02:34 -0000 Received: (qmail 18932 invoked by uid 22791); 5 Jan 2012 16:02:31 -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-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 16:02:17 +0000 Received: by wgbds11 with SMTP id ds11so553671wgb.12 for ; Thu, 05 Jan 2012 08:02:16 -0800 (PST) Received: by 10.227.204.146 with SMTP id fm18mr2271930wbb.7.1325779336259; Thu, 05 Jan 2012 08:02:16 -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 1sm142551896wiz.11.2012.01.05.08.02.12 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 08:02:13 -0800 (PST) Message-ID: <4F05C983.8080905@gmail.com> Date: Thu, 05 Jan 2012 16:02: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: <201112202215.pBKMFkrG002624@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201112202215.pBKMFkrG002624@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/msg00193.txt.bz2 On 12/20/2011 10:15 PM, Ulrich Weigand wrote: > I wrote: >> Pros of this method would be: >> >> - New target objects are quite generic and well-defined. >> >> - "info proc" now can go back to display info about arbitrary processes. >> >> - No new remote protocol packets for TARGET_OBJECT_FILE. >> >> >> Cons of the method: >> >> - Need new remote protocol packet for TARGET_OBJECT_SYMLINK after all. >> >> - Synthesizing file contents for core files is a bit more awkward, since >> you have to recognize particular /proc/PID/... file names. >> >> >> The alternative to TARGET_OBJECT_FILE/SYMLINK would be to provide a set >> of target_file_... accessor routines that map to native IO for native >> targets and hostio for remote targets, again with a gdbarch option to >> synthesize file contents from core files. > > I actually completed an implementation of this (second) method, before > I noticed that it fundamentally does not work with the current remote > protocol, for one simple reason: I cannot open /proc/PID/... because > I do not even know the PID to use. With the remote target, the "PID" > used within GDB may have no relationship whatsoever to the actual PID > on a Linux remote target; in fact, it usually is the "magic" 42000 ... In extended-remote (w/ multiprocess extensions on), we do know the PID, because the TID's are in the form pPID.TID. With regular remote, we only know the PID on "attach", because the user typed it, otherwise we fall back to the magic 42000. But why not simply fix this? We can query the remote end for the current process's ID, with target remote, and use that pid if supported, otherwise fall back to the current magic 42000 use. All the options so far require new packets, so this doesn't seem to make it worse. The tdep code in question is handling linux specific bits, so it can bail out on the magic 42000 safely. Another option, perhaps the cleanest, is to start allowing the multiprocess thread id extensions with plain "target remote". GDB currently only sends "multiprocess+" qSupported feature if connecting in extended-remote mode. I can help and try this is you'd like. Not knowing the current remote process' PID seems like yet another generic and unnecessary limitation on Linux targets. E.g., in the I/T sets series, I added a way to build sets with prefix letters, like 'i' for inferiors, 't' for threads, 'a' for Ada tasks, and had planned to use 'p' for processes. To be useful with plain "target remote" against gdbserver, the latter would require this change as well. > While in some cases, the (a) remote PID may be encoded into the GDB > TID field,I cannot use this in -tdep code either, because when used > with the native target, the TID is never a PID/LWP. Not sure what example you're referring to. :-(