gdb: don't use inferior_ptid in linux_nat_wait_1
authorSimon Marchi <simon.marchi@polymtl.ca>
Mon, 14 Sep 2020 15:51:04 +0000 (11:51 -0400)
committerSimon Marchi <simon.marchi@efficios.com>
Mon, 14 Sep 2020 15:51:21 +0000 (11:51 -0400)
commit677c92fe9a530f3f8959b8a0e311f58f9a616fa4
treed4e7ef4ff0853d0e81600c3605896ec389e9fac6
parent3eba3a011a89c75c10bd1860eee4589e65697165
gdb: don't use inferior_ptid in linux_nat_wait_1

target_ops::wait implementations should not rely on the value of
inferior_ptid on entry.  While looking at another wait-related patch, I
noticed that the code in linux_nat_wait_1, checking for a newly created
process, did just that.  This patch fixes it.  Note that I didn't see
any bug, this "fix" is simply to make the function respect the
target_ops::wait contract.

Instead of checking inferior_ptid, check for the passed in `ptid`
value.

During startup, linux_nat_wait_1 gets called a few times with the
pid-only ptid, while startup_inferior waits for the expected number of
exec events.  For this reason, I needed to add a `find_lwp_pid` call to
ensure that the actions of changing the main thread's ptid, and adding
the initial lwp, were done only once for a given process.

This was not needed before, since thread_change_ptid, through the
thread_ptid_changed observer, ends up changing inferior_ptid.  So the
second time around, inferior_ptid was not a pid-only ptid.

That find_lwp_pid won't add much overhead, as it will only be called
when the ptid is a pid-only ptid.  And AFAIK, that only happens during
inferior startup.

An alternative to that `find_lwp_pid` call might be to make
startup_inferior realize that the main thread has changed ptid, and make
it wait for the new ptid.  But that doesn't look easy to do.

Regtested on amd64/Linux.

gdb/ChangeLog:

* linux-nat.c (linux_nat_wait_1): Don't use inferior_ptid when
checking for initial lwp.

Change-Id: I8f1d5c766f5cb2a29c948bc75fa4582d7130c23f
gdb/ChangeLog
gdb/linux-nat.c