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

[Pedro Alves <pedro at codesourcery dot com>]

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.

> > > In my mind, the proposed TARGET_OBJECT_PROC would fall into the second
> > > category, that is, it provides access to pre-existing, operating-system
> > > defined contents, while simply abstracting the means of delivery.  In
> > > particular, I would not expect the "provider side" (Linux native target
> > > or gdbserver code) to ever implement any sort of "conversion" of the
> > > contents.  If there ever should be changes to the contents of /proc
> > > files, the task of adapting to those changes should lie solely on
> > > the gdbarch code that consumes the TARGET_OBJECT_PROC objects.
> > 
> > How are we making "info proc map" work with core files
> > with this?  I'd imagine the core target falling back to the gdbarch
> > method, but are we then making the core target synthesize TARGET_OBJECT_PROC
> > objects for the gdbarch method to consume?  That's where the bit
> > about "I don't expect the "provider side (...) to ever implement any
> > sort of "conversion" of the contents" seems to fall short.
> 
> My thoughts for this were for core_xfer_partial to handle the
> TARGET_OBJECT_PROC case by calling into a new gdbarch routine
> gdbarch_core_xfer_proc or so (along the lines of
> gdbarch_core_xfer_shared_libraries).  The linux-tdep implementation
> of this would then synthesize /proc/../map contents corresponding
> to the core file.

Okay, as suspected.  I guess I can live with that.

> (In the alternative, we could just have a generic gdbarch_core_xfer_partial
> routine and move some of the existing platform-specific stuff there.)
> 
> It's true that in this case, we would synthesize /proc output, but in
> a sense that's just because the kernel didn't provide it --  in theory,
> the kernel could put /proc file contents into core file notes, just like
> it does e.g. with spufs contents ...

Interesting.  Didn't know that.  Makes some sense.

> Also, the code synthesizing /proc output would be in one place right
> next to the code parsing /proc output, both in linux-tdep.c.  So it
> shouldn't be much of a maintenance hazard going forward to make sure
> they keep in agreement ...
> 
> > > Of course, as you say, this means that TARGET_OBJECT_PROC really only
> > > can ever be consumed by OS-specific, usually gdbarch code.  (But that's
> > > still better than having *native-target-only* code IMO.)
> > 
> > If GDB already needs to know what it is reading, then this could also be
> > implemented by having the gdbarch hook open/read remote:/proc/PID/maps ?
> > No new target object or packets necessary?  Because I'm not seeing what
> > TARGET_OBJECT_PROC brings over that (though I'm still confused on how
> > "info proc map" on cores is meant to be implemented with this).
> 
> 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.

> 
> However, this would mean that gdbarch code would have to know whether or
> not it runs on a remote target, or on a Linux native target (we wouldn't
> want to access /proc on some system where this isn't available or maybe
> does something different).  

Not if we design it right.  If we want to read a target path, we just use
a mechanisnm to read a target path.  The fact that on a Linux 
native target that ends up accessing the host filesystem is of concern to
the target backend alone.  It's still a target path.  

(We already have a clear distinction between a host and target path in
some places nowadays.  See e.g., solib.c:solib_find, and its use
of HAS_TARGET_DRIVE_SPEC, IS_TARGET_ABSOLUTE_PATH, etc..)

> Also, it wouldn't work for core files.

I think it would.

> That's why I'm suggesting separating *accessing* the data (into target
> code via TARGET_OBJECT_PROC) from *parsing* the data (into gdbarch code).

Right, but it's still separated with hostio transfers.

> [ 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.

-- 
Pedro Alves