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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:
> On Tuesday 06 December 2011 16:46:04, Ulrich Weigand wrote:
> > Pedro Alves wrote:
> > > On Monday 05 December 2011 14:52:04, Ulrich Weigand wrote:
> 
> > It seems to me that the original user request was along the lines:
> > users are familar with the "info proc mappings" command and use it
> > frequently; but the command doesn't work remotely and with core files,
> > can't we fix that?
> 
> We should read past what users literaly say, and infer what
> they really want --- to be able to read the mappings of core
> files.  Users get used to what we give them -- info proc is what
> only had.  They can get used to whatever else we give them.  :-)
> 
> Anyway, I'm just playing the devil's advocate, I actually agree
> with "info proc" for cores.  :-)  I think it was useful to have
> this part of discussion, so that if/when this goes through, it
> won't have gone without being discussed.

OK, thanks.

> > For remote, we could do something along those lines (we cannot directly
> > use "remote:" because this is only implemented for BFD access -- but
> > we could use the underlying remote_hostio_pread etc. routines).
> 
> Right, I did not mean to imply "remote:" literally.  
> I kind of see "remote:/proc/PID/maps" as a target path mounted
> on the host, so "remote:/proc/PID/maps" is a really a host path.
> The "/proc/PID/maps" path, what the code in question wants to get at, is
> a target path.  I was trying to say is that the gdbarch hook would always
> open/read "/proc/PID/maps" from the target, instead of from the host.  On
> native targets, that ends up falling back to the host filesystem.  For
> remote targets, that would use the existing hostio mechanism, the same
> as used by "remote:".  This suggests e.g., a target method to
> fully open/read/close a target path and return the file's contents (like
> you say), or, alternatively, wrap the hostio mechanism in a
> ui-file (through open/read/write/close/... target methods perhaps), and
> use that.

I see.  It still seems that the target object mechanism should be a good
fit for that; but instead of talking about a specific TARGET_OBJECT_PROC,
we're now talking about a generic TARGET_OBJECT_FILE -- which may have been
part of the original target object design to start with, see e.g. the 
comment in target.h:

  /* Possible future objects: TARGET_OBJECT_FILE, ...  */


> > [ I guess we could implement TARGET_OBJECT_PROC without a new packet type
> > but implementing TARGET_OBJECT_PROC xfer in remote.c via remote_hostio_pread.
> > This makes the assumption that the remote side always has a Linux-style /proc,
> > however.  Not sure whether we should make that assumption ... ]
> 
> If the OS does has something else entirely, then the gdbarch method will
> be aware, because it is the gdbarch method itself that retrieves
> the data.  It may even use something completely different, not
> based on filesystems at all.  Otherwise, we're back at making targets
> fake a file system and proc interface they don't have, where we might
> as well return some structured data.

Hmm, OK.  I agree.  So this option would be to:

- Define a new TARGET_OBJECT_FILE.  The "annex" is simply a full path name
  of a file on the target system.

- Implement its xfer method for native targets, probably in inf-ptrace.c
  (or maybe even as generic default in target.c), via native file I/O.

- Implement its xfer method for remote targets in remote.c, using the
  hostio mechanism (no new packets required).

- Implement its xfer method for core files via a gdbarch callback allowing
  the arch to synthesize contents of arbitrary files.


Note that to fully implement "info proc", we also need to be able to
read the link path names for files that happen to be symbolic links.
For TARGET_OBJECT_PROC, I simply defined the target object that way;
this doesn't really make sense for TARGET_OBJECT_FILE.  So we might
want to add another target object type TARGET_OBJECT_SYMLINK that
provides that capability.  Unfortunately, this does mean we need a
new remote protocol packet, since hostio does not support readlink ...


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.

This would require the exact same set of remote protocol extensions
as the above (i.e. a vFile:readlink or so), and allow the exact same
set of capabilities; this is purely a question of what GDB-internal
interface is preferable.


Thoughts?

Bye,
Ulrich

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