This is the mail archive of the gdb-patches@sourceware.org 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)


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



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