This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 03/22/2017 01:00 AM, Pedro Alves wrote:

>> 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?
> 
> Right, on Linux there's always an lwp.  Before NPTL, the 
> /proc/<pid>/task/<tid> path didn't exist at all, but we no longer
> support LinuxThreads.

I think I read the question all backwards.  I understood you were
asking whether the <tid> in that /proc patch would be 0 in some
cases...  Sorry.

So trying again:

In linux-nat.c, you only see a ptid without an lwp filled in during
early child process startup, either while attaching (see 
thread_change_ptid call in linux_nat_attach), or while doing the first
iteration of the fork-child.c:startup_inferior dance.  The lwp is filled in
at the top of linux_nat_wait_1 [1].  I don't think we access /proc between
the initial fork and that spot.  If we did, we'd be accessing the process
while it was still executing the shell, and startup_inferior was invented
exactly to prevent that sort of inadvertent access.

[1] And that is another inferior_ptid hack that we should get
rid of ... somehow ...

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]