[rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command)

Pedro Alves palves@redhat.com
Wed Jan 11 16:38:00 GMT 2012 

On 01/09/2012 03:43 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>> On 01/05/2012 07:53 PM, Ulrich Weigand wrote:
>>> Well, I guess one could implement some heuristics along those lines
>>> that do indeed work with Linux native and gdbserver targets.
>>> But this would still make a number of assumptions about how those fields
>>> are used -- which may be true at the moment, but not guaranteed.
>>>
>>> In particular, it seems to me that the remote protocol specification
>>> considers TID values to be defined by the remote side; the host side
>>> should only use them as identifiers without interpreting them.
>>
>> Yes, that is true in general.
>>
>>> While gdbserver does use the LWPID here, I don't think it is guaranteed that
>>> other implementations of the remote protocol do the same, even on
>>> Linux targets (i.e. where linux-tdep files get used).
>>
>> ... however, let's revisit the problem with a fresh start.
>>
>> We have a command "info proc FOO PID", that accepts any target process ID,
>> whose description is:
>>
>>   (gdb) help info proc
>>   Show /proc process information about any running process.
>>   Specify any process id, or use the program being debugged by default.
>>
>> Let's ignore the "or use the program being debugged by default" part
>> for now; it is a (big) convenience, and a separate problem, one of mapping
>> the program being debugged to a process id.  (The dropping of the
>> support for specifying any process id in the proposed implementations
>> seems more like accommodating the implementation, so let's step back on
>> that too.)
> 
> It seems to me we're getting to the core of the problem here.  For the
> existing "info proc" command, it indeed makes sense to talk about
> "process IDs", *because* the command is specific to a (native) target
> that supports processes and uses process IDs.
> 
> Except for this, common GDB user interface commands do not currently
> refer to "process IDs"; while GDB obviously used "ptid_t" internally,
> it is *interpreted* only by target code, common code at most uses it
> for comparions (is this the same process as another one).
> 
> [ The one obvious exception is the "attach" command which also takes
> a process ID.  However, this is arguably also a target-specific command,
> in that the generic implementation quickly calls through to target code
> that implements the operation, starting with *parsing the argument*. ]
> 
> Instead of refering to process IDs, GDB commands usually operate on
> the "current inferior", or else take GDB inferior (or thread) IDs as
> argument, which have no direct connection to the underlying OS
> process IDs.
> 
> It seems to me this was a deliberate decision to try and isolate the
> common GDB code and user interfaces from OS implementation details:
> GDB is supposed to work just the same on targets where there are no
> processes, or where they are identified by different means that just
> an integer ID.
> 
> 
> Now, given the "anomaly" of the "info proc" command as is, I guess
> there's two ways to look at how to move forward:
> 
> - We could say the anomaly was a mistake that we want to get rid of.
>   In this view, it naturally follows that we remove the PID argument
>   option and have the command operate on the "current inferior" as
>   all other commands.  This also makes an underlying interface that
>   would retrieve proc file content of the current inferior natural.
>   (This is what my patch set has implemented.)
> 
> - 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.

> Now, I'm not necessarily opposed to the second approach, I'm just
> not sure I see all the consequences ...   At a minimum, the use
> of the "magic 42000" becomes problematic if there is any chance
> the ptid_t gets exposed to the user at any point.
> 
>> So this sub-problem can be simply specified as:
>>
>>    Given a gdb inferior or thread, return it's target process id.
>>
>> Now, we can come up with a new method to retrieve that info from
>> the server.  However, all the Linux targets I know about that have
>> /proc contents access (gdbserver), have a 1:1 mapping in the RSP
>> between RSP process, and target process, so we might as well start
>> out with defaulting to assume that, and add such a mechanism when
>> we find a need for it.  IMO.
> 
> 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.

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.

> 
>>  > So all in all, this still looks a violation of abstraction layers
>>  > to me,
>>
>> So I see this as two distinct, but related problems.  And when I look
>> at the /proc retrieval part alone, I favor the remote filesystem
>> access, as the most natural way to transparently make the command
>> work with remote targets.  And for cores too, as you yourself
>> mentioned, the kernel can put /proc contents in cores, and, I could
>> imagine taking a snapshot of /proc for the whole process tree (either
>> above a given process (children, siblings, etc.), or starting at
>> PID 1, and storing that in, or along the core, to be something useful.
> 
> I could imaging a core file of a process containing snapshots of /proc
> files *for that process*.  It would seem rather odd to me to have /proc
> files of *other* processes as part of a core file.  But that's certainly
> a side discussion ...
> 
>>  > which is the main reason why I advocated going back to the
>>  > TARGET_OBJECT_PROC approach ...
>>
>> If you're still not convinced, and others don't support my view,
>> than I will step back and won't block your going forward with that.
>> However, what did you think of my earlier comments regarding
>> splitting that into separate objects?
> 
> 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.

> 
> Bye,
> Ulrich
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-target_fileio.diff
Type: text/x-patch
Size: 5080 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02-proc_access_target.diff
Type: text/x-patch
Size: 7502 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03-process_id.diff
Type: text/x-patch
Size: 4864 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 04-allow_multi_on_remote.diff
Type: text/x-patch
Size: 3066 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 05-abstract_if_necessary.diff
Type: text/x-patch
Size: 4483 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment-0004.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: series
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20120111/6783b821/attachment.ksh>

More information about the Gdb-patches mailing list