Re: [0/9]#2 Fix lost siginfo_t

[Pedro Alves <pedro at codesourcery dot com>]

I must confess that my knee-jerk reaction to the main idea
of the patchset is "I'm not convinced this is a good idea".
A thread can't be stopped for more than one reason at the
same time, so why isn't target_wait plus an on-the-side
interface to get at the expensive-to-get siginfo enough?

I've just extracted the testsuite hunks from patches 7 and 8,
so that I've got the new gdb.threads/siginfo-threads.exp test
on my pristine mainline checkout, with no other changes from the
series, and ran the test against amd64-linux gdbserver:

>make check RUNTESTFLAGS="--target_board=native-gdbserver siginfo-threads.exp"
(..)
                === gdb Summary ===

# of expected passes            22



compared to native amd64-linux gdb, which indeed has these failures:

Running ../../../src/gdb/testsuite/gdb.threads/siginfo-threads.exp ...
FAIL: gdb.threads/siginfo-threads.exp: signal 1 si_signo
FAIL: gdb.threads/siginfo-threads.exp: signal 1 si_pid
FAIL: gdb.threads/siginfo-threads.exp: signal 2 si_signo
FAIL: gdb.threads/siginfo-threads.exp: signal 2 si_pid
FAIL: gdb.threads/siginfo-threads.exp: signal 3 si_signo
FAIL: gdb.threads/siginfo-threads.exp: signal 3 si_pid
FAIL: gdb.threads/siginfo-threads.exp: continue to break-at-exit

                === gdb Summary ===

# of expected passes            15
# of unexpected failures        7


I'm guessing that this is because of gdbserver/linux-low.c's
much better handling of pending signals than linux-nat.c's.
(see linux-low.c's lwp->pending_signals, and linux_resume_one_lwp,
for example).

-- 
Pedro Alves