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

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 07 December 2011 16:24:31, Pedro Alves wrote:
> > 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.

BTW, from this perspective, "remote:" would have been
better named "target:" IMO.

-- 
Pedro Alves