From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15470 invoked by alias); 20 Mar 2012 17:55:51 -0000 Received: (qmail 15461 invoked by uid 22791); 20 Mar 2012 17:55:50 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 17:55:33 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2KHtSNA004181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 13:55:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2KHtQEU032008; Tue, 20 Mar 2012 13:55:27 -0400 Message-ID: <4F68C48E.5040303@redhat.com> Date: Tue, 20 Mar 2012 17:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Doug Evans CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 3/5] s/struct process_info/struct inferior/ References: <1331909994-9473-1-git-send-email-yao@codesourcery.com> <1331909994-9473-4-git-send-email-yao@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-03/txt/msg00749.txt.bz2 On 03/20/2012 04:28 PM, Doug Evans wrote: > On Fri, Mar 16, 2012 at 7:59 AM, Yao Qi wrote: >> ITSET need a type `struct inferior' to represent a process. Its counter part >> in GDBserver is `struct process_info'. This patch is to rename `struct process_info' >> to `struct inferior', so that ITSET code in gdb/common can use 'struct inferior' >> unconditionally. > One thought that comes to mind is that if this renaming is good, then An `inferior' in GDB represents an abstraction that does not exist in GDBserver. For example, you have the same inferior before creating the process, and after the process exits: inferior 1 -> no process *start* inferior 1 -> process 7450 *process 7450 exits* inferior 1 -> no process The remote serial protocol only talks about processes. There's no way to create a remote "inferior" before creating a process. All the thread ids with the multi-process extension on are augmented with `pPID.' to identify the process (so we have pPID.TID instead of pTID). Note the `p', that obviously stands for "process". So I'd prefer to keep the process nomenclature in gdbserver, to clearly separate the notion of host side inferior vs target side process. Clearly, in order for GDB to send any itset-like spec to the target ("i1-3" in the current form, for example), GDB needs to convert the GDB inferior IDs to target process IDs. Imagine inferior 1 is process 345. If while doing that spec "conversion", you end up sending "i345" to the target, you're doing it wrong... The intention was to support being able to specifying target process ids in itsets (even for native debugging) as well, and those would naturally use the `p' prefix. So you'd be able to say e.g., "i1,p345" to mean inferior 1, and process with pid 345 (which could be inferior 2, for example). It doesn't seem like you'd be able to convert dynamic itsets involving inferior ids or gdb thread ids (which are most) retaining the dynamic-ness, which means that the conversion ends up only with a list of already-known objects, which results in a much simpler and easier to specify (and maintain forever) syntax on the target side. There's also the non-id predicates, which I have on idea on how they are intended to be converted. I'm not convinced this forwarding of itset specs to the target is sufficiently thought through and sufficiently baked. -- Pedro Alves