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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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

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.

Any suggestions?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com