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