[v2] Remove lwp -> pid conversion in linux_nat_xfer_partial

  New in v2:

  - Use lwp in linux_proc_xfer_partial and linux_proc_xfer_spu.
  - Updated commit message (stole some of Pedro's text)

The linux_nat_xfer_partial does a conversion of inferior_ptid: if it's
an LWP (ptid::lwp != 0), it builds a new ptid with the lwp as
the pid and assigns that temporarily to inferior_ptid.  For example, if
inferior_ptid is:

  { .pid = 1234, .lwp = 1235 }

it will assign this to inferior_ptid for the duration of the call:

  { .pid = 1235, .lwp = 0 }

Instead of doing this, this patch teaches the inf-ptrace implementation
of xfer_partial to deal with ptids representing lwps by using
get_ptrace_pid.

Also, in linux_proc_xfer_spu and linux_proc_xfer_partial, we use ptid_get_lwp
instead of ptid_get_pid.  While not strictly necessary, since the content of
/proc/<pid> and /proc/<lwp> should be the same, it's a bit safer, because:

- some files under /proc/<pid>/ may not work if the <pid> thread is
  running, just like ptrace requires a stopped thread.  The current
  thread's lwp id is more likely to be in the necessary state (stopped).

- if the leader exits, and goes zombie, then several files under
  "/proc/<pid>" won't work, though using "/proc/<pid>/task/<tid>" would.
  The latter path form is also generally better for being robust in
  the case TID exits and is reused in another process, much like
  tkill vs tgkill.

The testsuite found no regression on native amd64 linux.

gdb/ChangeLog:

    * inf-ptrace.c (inf_ptrace_xfer_partial): Get pid from ptid
    using get_ptrace_pid.
    * linux-nat.c (linux_nat_xfer_partial): Don't set/restore
    inferior_ptid.
    (linux_proc_xfer_partial, linux_proc_xfer_spu): Use lwp of
    inferior_ptid instead of pid.
---
 gdb/inf-ptrace.c |  2 +-
 gdb/linux-nat.c  | 13 +++----------
 2 files changed, 4 insertions(+), 11 deletions(-)
  

On 03/22/2017 03:02 AM, Simon Marchi wrote:
> New in v2:
> 
>   - Use lwp in linux_proc_xfer_partial and linux_proc_xfer_spu.
>   - Updated commit message (stole some of Pedro's text)

Thanks!

> - if the leader exits, and goes zombie, then several files under
>   "/proc/<pid>" won't work, though using "/proc/<pid>/task/<tid>" would.
>   The latter path form is also generally better for being robust in
>   the case TID exits and is reused in another process, much like
>   tkill vs tgkill.

The part about TID-reuse robustness actually doesn't make sense here
yet, though, since this patch is not switching to "/proc/<pid>/task/<tid>".

So reduce that to:

- if the leader (<pid>) had exited and is thus now zombie, then several
  files under "/proc/<pid>" won't work, while they will if you use
  "/proc/<lwp>".

Otherwise LGTM.

Thanks,
Pedro Alves
  

On 2017-03-22 07:28, Pedro Alves wrote:
>> - if the leader exits, and goes zombie, then several files under
>>   "/proc/<pid>" won't work, though using "/proc/<pid>/task/<tid>" 
>> would.
>>   The latter path form is also generally better for being robust in
>>   the case TID exits and is reused in another process, much like
>>   tkill vs tgkill.
> 
> The part about TID-reuse robustness actually doesn't make sense here
> yet, though, since this patch is not switching to 
> "/proc/<pid>/task/<tid>".
> 
> So reduce that to:
> 
> - if the leader (<pid>) had exited and is thus now zombie, then several
>   files under "/proc/<pid>" won't work, while they will if you use
>   "/proc/<lwp>".
> 
> Otherwise LGTM.

Pushed with that fixed, thanks!