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 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.
 
> > In particular, with Linux native targets, "pid" is what getpid () returns;
> > "lwp" is the Linux task ID -- which is equal to the pid for single-threaded
> > processes, and "tid" is the value of "pthread_t" for the thread.
> 
> Ah.  I see the confusion.  That's no longer the case for a couple years.
> We only store the LWP id in the ptid.  The TID is always empty.  We don't need
> the pthread_id, given Linux's 1:1 thread model.

Ah right, I missed that.

> > Now, with the remote target, "pid" seems to be the magic 42000; "lwp" is
> > never used, and "tid" is used for the thread ID used with the remote
> > protocol -- and when using gdbserver, the latter is actually the LWP ID
> >   / Linux task ID.
> 
> 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.  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).

So all in all, this still looks a violation of abstraction layers
to me, which is the main reason why I advocated going back to the
TARGET_OBJECT_PROC approach ...


Bye,
Ulrich


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