This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: alves dot ped at gmail dot com
- Cc: gdb-patches at sourceware dot org, jan dot kratochvil at redhat dot com, sergiodj at redhat dot com
- Date: Tue, 20 Dec 2011 23:15:46 +0100 (CET)
- Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command)
> 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.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE