Re: [PATCH] Remove lwp -> pid conversion in linux_nat_xfer_partial

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2017-03-21 19:58, Pedro Alves wrote:
> Yeah...  The stuffing of lwpids in the inferior_pid integer global was 
> clearly
> a hack.  But when later GDB grew the "ptid" structure, this shuffling
> made some sense -- way back then, when we had LinuxThreads instead of 
> NTPL, the
> kernel didn't really have any concept of "threads" or "lwps".  Threads
> were really each a heavy weight process.  So in that sense, in the 
> abstract,
> it made some sense to have inf-ptrace.c only ever think about 
> processes.  But,
> over the years we've been running into issues with that, and over time
> the inf-ptrace.c layer as been adjusted to understand these ptids.
> Commit 90ad5e1d4f34d0
> ("Linux/ptrace: don't convert ptids when asking inf-ptrace layer to 
> resume LWP")
> is one that comes to mind.  You've running into some left overs of a 
> long
> slow conversion...

Ok, thanks for the history bits.

>> There is also linux_proc_xfer_partial and linux_proc_xfer_spu, which
>> both only use the pid field of inferior_ptid and ignore lwp.  However,
>> since they use "/proc/<pid>", using the id of any thread in the 
>> process
>> will give the same result (AFAIK).
> 
> It's generally better to use the lwp id:
> 
> - 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.
>   (try poking at leader-exit.exp a bit.)
>   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.

I thought that the process exited whenever the main thread exits, that's 
not the case?  I guess not if there's a test for it...

> So if possible to switch those spots too, I'd recommend/prefer it.

Ok, I'll just replace ptid_get_pid with get_ptrace_pid* in this patch 
and look at using /proc/<pid>/task/<tid> after.  When doing the latter, 
do I still have to consider cases where ptid is a single-process/thread 
ptid (lwp == 0)?  From my experience, there's always a lwp on Linux, but 
perhaps there are some setups I don't know about with which it can 
happen?

* using get_ptrace_pid is an abuse of terminology, since we're not using 
ptrace, but it does what we want.

Thanks,

Simon