Re: [PATCH 3/5] s/struct process_info/struct inferior/

[Pedro Alves <palves at redhat dot com>]

On 03/20/2012 04:28 PM, Doug Evans wrote:

> On Fri, Mar 16, 2012 at 7:59 AM, Yao Qi <yao@codesourcery.com> 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