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

Ulrich Weigand
2011-12-20T22:16:07Z

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