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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:
> On 01/05/2012 07:53 PM, Ulrich Weigand wrote:
> > Well, I guess one could implement some heuristics along those lines
> > that do indeed work with Linux native and gdbserver targets.
> > But this would still make a number of assumptions about how those fields
> > are used -- which may be true at the moment, but not guaranteed.
> >
> > In particular, it seems to me that the remote protocol specification
> > considers TID values to be defined by the remote side; the host side
> > should only use them as identifiers without interpreting them.
> 
> Yes, that is true in general.
> 
> > While gdbserver does use the LWPID here, I don't think it is guaranteed that
> > other implementations of the remote protocol do the same, even on
> > Linux targets (i.e. where linux-tdep files get used).
> 
> ... however, let's revisit the problem with a fresh start.
> 
> We have a command "info proc FOO PID", that accepts any target process ID,
> whose description is:
> 
>   (gdb) help info proc
>   Show /proc process information about any running process.
>   Specify any process id, or use the program being debugged by default.
> 
> Let's ignore the "or use the program being debugged by default" part
> for now; it is a (big) convenience, and a separate problem, one of mapping
> the program being debugged to a process id.  (The dropping of the
> support for specifying any process id in the proposed implementations
> seems more like accommodating the implementation, so let's step back on
> that too.)

It seems to me we're getting to the core of the problem here.  For the
existing "info proc" command, it indeed makes sense to talk about
"process IDs", *because* the command is specific to a (native) target
that supports processes and uses process IDs.

Except for this, common GDB user interface commands do not currently
refer to "process IDs"; while GDB obviously used "ptid_t" internally,
it is *interpreted* only by target code, common code at most uses it
for comparions (is this the same process as another one).

[ The one obvious exception is the "attach" command which also takes
a process ID.  However, this is arguably also a target-specific command,
in that the generic implementation quickly calls through to target code
that implements the operation, starting with *parsing the argument*. ]

Instead of refering to process IDs, GDB commands usually operate on
the "current inferior", or else take GDB inferior (or thread) IDs as
argument, which have no direct connection to the underlying OS
process IDs.

It seems to me this was a deliberate decision to try and isolate the
common GDB code and user interfaces from OS implementation details:
GDB is supposed to work just the same on targets where there are no
processes, or where they are identified by different means that just
an integer ID.


Now, given the "anomaly" of the "info proc" command as is, I guess
there's two ways to look at how to move forward:

- We could say the anomaly was a mistake that we want to get rid of.
  In this view, it naturally follows that we remove the PID argument
  option and have the command operate on the "current inferior" as
  all other commands.  This also makes an underlying interface that
  would retrieve proc file content of the current inferior natural.
  (This is what my patch set has implemented.)

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

Now, I'm not necessarily opposed to the second approach, I'm just
not sure I see all the consequences ...   At a minimum, the use
of the "magic 42000" becomes problematic if there is any chance
the ptid_t gets exposed to the user at any point.

> So this sub-problem can be simply specified as:
> 
>    Given a gdb inferior or thread, return it's target process id.
> 
> Now, we can come up with a new method to retrieve that info from
> the server.  However, all the Linux targets I know about that have
> /proc contents access (gdbserver), have a 1:1 mapping in the RSP
> between RSP process, and target process, so we might as well start
> out with defaulting to assume that, and add such a mechanism when
> we find a need for it.  IMO.

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

>  > So all in all, this still looks a violation of abstraction layers
>  > to me,
> 
> So I see this as two distinct, but related problems.  And when I look
> at the /proc retrieval part alone, I favor the remote filesystem
> access, as the most natural way to transparently make the command
> work with remote targets.  And for cores too, as you yourself
> mentioned, the kernel can put /proc contents in cores, and, I could
> imagine taking a snapshot of /proc for the whole process tree (either
> above a given process (children, siblings, etc.), or starting at
> PID 1, and storing that in, or along the core, to be something useful.

I could imaging a core file of a process containing snapshots of /proc
files *for that process*.  It would seem rather odd to me to have /proc
files of *other* processes as part of a core file.  But that's certainly
a side discussion ...

>  > which is the main reason why I advocated going back to the
>  > TARGET_OBJECT_PROC approach ...
> 
> If you're still not convinced, and others don't support my view,
> than I will step back and won't block your going forward with that.
> However, what did you think of my earlier comments regarding
> splitting that into separate objects?

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?

Bye,
Ulrich

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