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

[Pedro Alves <alves.ped@gmail.com>]

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.  :-(