This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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?


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]