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

Ulrich Weigand
2012-01-11T17:54:07Z

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