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

[Pedro Alves <alves dot ped at gmail dot com>]

On 01/05/2012 06:02 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
> > On 12/20/2011 10:15 PM, Ulrich Weigand wrote:
> > > I actually completed an implementation of this (second) method, before
> > > I noticed that it fundamentally does not work with the current remote
> > > protocol, for one simple reason:  I cannot open /proc/PID/... because
> > > I do not even know the PID to use.  With the remote target, the "PID"
> > > used within GDB may have no relationship whatsoever to the actual PID
> > > on a Linux remote target; in fact, it usually is the "magic" 42000 ...
> >
> > In extended-remote (w/ multiprocess extensions on), we do know the PID,
> > because the TID's are in the form pPID.TID.  With regular remote, we only
> > know the PID on "attach", because the user typed it, otherwise we fall back to
> > the magic 42000.  But why not simply fix this?  We can query the remote
> > end for the current process's ID, with target remote, and use that pid if
> > supported, otherwise fall back to the current magic 42000 use.   All the
> > options so far require new packets, so this doesn't seem to make it worse.
> > The tdep code in question is handling linux specific bits, so it can
> > bail out on the magic 42000 safely.
>
> 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.

We could easily have an inferior->fake_pid_p boolean flag in
the inferior struct if we needed.

> > Another option, perhaps the cleanest,
> > is to start allowing the multiprocess thread id extensions with
> > plain "target remote".  GDB currently only sends "multiprocess+" qSupported
> > feature if connecting in extended-remote mode.  I can help and try this is
> > you'd like.
>
> Yes, this does sound like an interesting approach.

I'll give it a try if necessary, but with your idea below, it may not.

> > > While in some cases, the (a) remote PID may be encoded into the GDB
> > > TID field,I cannot use this in -tdep code either, because when used
> > > with the native target, the TID is never a PID/LWP.
> >
> > Not sure what example you're referring to.  :-(
>
> Well, GDB's "ptid_t" contains three fields: pid, lwp, and tid.  From what
> I recall, these are used somewhat differently on different targets.

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

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

> What I was trying to say with the statement above is: if I knew the LWP
> ID, I could use this to access /proc, since there is a /proc/... entry
> for all LWP IDs as well as for the main PID.  And in fact, at least
> for multi-threaded processes, I *do* know the LWP ID, since it is in fact
> used as the TID field of the ptid_t with remote/gdbserver targets.

That's a good point.

> The problem is, with the native target, the TID field is used to hold
> the "pthread_t" value, *not* the LWP ID.

We're good then, because that is not true on Linux anymore.
The TID field is not used for anything, and the LWP ID is in
the LWPID field.

(Actually back when we used to fill in the TID field with the pthread_t
value, we also put the LWP id in the lwpid field of the ptid, so if LWPID
was 0 and TID was not, the PTID must have been a remote one.)

> Since -tdep code needs to
> work with either target, I cannot really interpret that field in any
> way ...

> Bye,
> Ulrich