gdb: Avoid using W_STOPCODE(0) as this is ambiguous on MIPS
authorAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 3 Jul 2018 18:02:48 +0000 (19:02 +0100)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Mon, 6 Aug 2018 07:49:39 +0000 (08:49 +0100)
commit953473375500a809fbb3eca3efa4dbb670c3a32f
treec1d2f82173e55b09761ad563a050ae1321bbee8b
parente968fc9b638e48a89e9a96804896c88a400e9be1
gdb: Avoid using W_STOPCODE(0) as this is ambiguous on MIPS

The MIPS target supports 127 signals, and this can create an ambiguity
in process wait statuses.  A status value of 0x007f could potentially
indicate a process that has exited with signal 127, or a process that
has stopped with signal 0.

In uClibc-ng the interpretation of 0x007f is that the process has
exited with signal 127 rather than stopped with signal 0, and so,
WIFSTOPPED (W_STOPCODE (0)) will be false rather than true as it would
be on most other platforms.

Given that it's pretty easy to avoid using W_STOPCODE (0), lets do that.

gdb/ChangeLog:

* linux-nat.c (linux_nat_target::follow_fork): Avoid using
'W_STOPCODE (0)' as this could be ambiguous.
gdb/ChangeLog
gdb/linux-nat.c