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


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