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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Pedro Alves wrote:
> On 01/09/2012 03:43 PM, Ulrich Weigand wrote:
> > - We say instead that, yes, we *want* OS PIDs to be used as first-
> >   class user interface elements.  But this means to me that we
> >   need to more generally make OS PIDs present in GDB common code
> >   so that common code is at least able to associate its internal
> >   notions of "inferior" with those IDs.  At a minimum, this would
> >   imply we no longer consider "ptid_t" values to be opaque to
> >   GDB common code, but rather enforce that they agree with user-
> >   visible OS PID values.
> 
> Note that I'm not talking about the notion of a "process id" escape
> escape to common/core code, but only to the linux gdbarch/osabi
> specific bits; or other code that can deal with it, guarded by
> "is there a notion of a process id on this target.

Ah, I see.  OK, I guess this make sense ...

> > I don't quite understand what you mean here.  Could you elaborate
> > how you propose to implement this routine "return the target process
> > ID of a given GDB inferior/thread" without remote interface changes?
> > This was exactly the "magic 42000" problem I was running into ...
> 
> As mentioned before, by broadcasting support for multi-process extensions
> even with "target remote" (but don't allow debugging multiple processes),
> and defaulting to assume a 1:1 mapping between target process id
> and RSP process id, until some target needs to do something else, at
> which point we define a new packet.

OK, that was the piece I was missing.  Yes, if we enable the multi-process
extension, that should work.

> I've spent a bit today prototyping /proc access this way the way
> I was imagining it.  See the attached patch series.  This is far from
> complete.  It's just enough to get something working.

Ah, thanks!  I should have posted my work-in-progress patch series;
I had already implemented most of what's in your patches, except for
the process-id bits.  Sorry for causing you extra work!


So, both the features:
- enable multi-process extension to get better PID
- have an inferior flag to specify whether the PID is "fake" or
  corresponds to a target PID
make sense to me, and looks like they should be enabled anyway.  If we
can then implement /proc access without any further protocol extension,
I don't really have any objection ...

I'll integrate your suggestions with my WIP patches and see how far
I get.


> > I must admit I don't see what the benefit of this is supposed to be.
> > This seems to me to be the exact use case that "annex" is there to
> > cover: a bunch of information with related content semantics, which
> > are all accessed the same way, and the exact set is somewhat dynamic.
> > Not using the annex would mean defining a whole bunch of new packet
> > types, duplicated boilerplate code in GDB and gdbserver to hook them
> > up, and then still the drawback that every new /proc file that may
> > come up in the future will require extra code (including new gdbserver-side
> > code!) to support.  And for all those drawbacks, I don't see any single
> > benefit ...  Maybe you can elaborate?
> 
> - Decoupling of the objects in question from a "/proc" idea, so they
> can be more generally used in other scenarios, like e.g., a remote
> protocol implementation of target_pid_to_str (TARGET_OBJECT_PROC/exe).
> - Let GDB have a finer grained idea of what subset of /proc-ish objects
> are supported upfront (through qSupported), without any new mechanism.

I still don't quite see why we cannot do the same with using the annex.
In both cases, users in GDB would do some form of target_read and check
the error code; the only difference is whether they use TARGET_OBJECT_PROC
with a non-NULL annex, or else TARGET_OBJECT_PROC_xxx without annex.

But I guess if we don't do TARGET_OBJECT_PROC at all it doesn't matter.

Bye,
Ulrich

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