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

[Pedro Alves <pedro at codesourcery dot com>]

Hi Ulrich, sorry for the delay.  I haven't managed to read your patches yet.
I'll reaply here first.

On Wednesday 23 November 2011 16:32:08, Ulrich Weigand wrote:

> I'd really appreciate thoughts / suggestions on whether the above
> drawbacks are acceptable, and which option we should proceed with.

First, the reason Sergio added "info mappings" instead of making
"info proc mappings" work for core files, was that using "info proc"
for cores was objected.  I'm personally okay with it, but I think
that should be understood as not being a limitation of the design.

I have to say that I have reservations on this new TARGET_OBJECT_PROC
option.  It adds yet another generic abstraction (it almost looks like
TARGET_OBJECT_OSDATA reinvented), yet the data it sends over is not
really structured.  This maps nicely on linux, but, e.g, on procfs targets,
you have a bunch of different /proc implementations, it can actually be
awkward, in that you may need to translate whatever the real /proc/pid/foo
gives you into a format gdb expects.  The answer to that seems to be that GDB
will install a gdbarch handler for each OS that understands 
/proc/pid/foo for the target OS, but that means that either or both of core
gdb and the target (can result in weird wrong turns, if we add coping to
both ends) will have to keep up with whatever format changes happen
between OS revisions on the target side instead of being given a
structured, abstracted and simplified view (that could in turn be easily
marshalled in structured form to MI or python, if so desired).  And then
there's no default gdb-side gdbarch implementation, so GDB needs to be
aware of the random embedded OSs to be able to support "info proc foo".  
A structured format means that its definitely the target that gets to keep up.

This is not a NAK, but I'm just saying I'm not fully convinced yet.

-- 
Pedro Alves