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

[Pedro Alves <alves.ped@gmail.com>]

On 01/05/2012 07:53 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>> On 01/05/2012 06:02 PM, Ulrich Weigand wrote:
>>> I'm wondering: How can I distinguish the "magic 42000" from
>>> a regular PID 42000 ?
>>
>> AFAIK, there's no such thing as a 42000 PID; PIDs on Linux are limited
>> to 16-bit.
>
> See my reply to Mark; this is no longer true in general these days.

Thanks.  Always learning.  However, the problem was knowing when
42000 was the magic PID, or when it was a real PID.  That
should not be a problem, because it is GDB itself that comes up
with the 42000 magic number, not the server.  It's just a GDB
implementation detail.

>> Right.  So in reality, only ever one of the tid or the lwpid fields is
>> non-zero.  And the one that is non-zero is the LWP id we want.
>
> 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.)

Now, we want to make this work on remote targets.  For several reasons
I've stated, I think this is best done with converting the always-host
open/read/close's into remote target filesystem operations.  To recap:

  - target objects aren't ideal for the case of reading files out of
    /proc for the case of reading them from random processes, not being
    debugged, that are currently running, because on the server side, you
    need to open/read/close the file descriptor at every partial transfer,
    which leads itself to corrupt transfers if the file changes between
    partial transfers, or, you need to cache the whole object (as we
    presently do for xml objects).  The latter has the downside of
    needing to hold on to the object in memory on the server side, and
    to assume GDB always reads the object starting from offset 0.  IMO,
    that's not a good assumption for binary objects.

  - A natural solution, is, IMO, realize we're already assuming a /proc
    target on the client (gdb) side, so the client might as well read
    the /proc files directly itself.

After this, we're now left with the "or use the program being debugged
by default" problem to solve.  This has a use in more scenarios, so it's
useful to state it as a problem in its own right.  Off-hand examples are,
I/T sets `p' prefix idea, and even remote core generation, so you can
write the correct PID on the core file.

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.

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

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