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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 30 Aug 2010 21:50:02 +0200, Pedro Alves wrote:
> 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?

Because linux-nat.c internals stop it on a different signal (SIGSTOP one) than
the interestign one (e.g. SIGUSR1) for which GDB was stopping.


> and ran the test against amd64-linux gdbserver:

I can confirm FSF gdbserver also works for me with
gdb.threads/siginfo-threads.exp .  The testcase also correctly SIGSTOPs its
getppid(), therefore gdbserver, which is the right target for the testcase.


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

I had to fix linux-nat.c for backport reasons anyway but I probably could keep
it only internal (and hack it more dirty without the FSF import intention).
I see I went needlessly far.

I am not sure how much interest is in pusing it for FSF linux-nat.c . I made
it more as a proof of concept before I start fixing gdb/remote.c (for ugdb).
I did not expect gdb/remote.c needs no changes at all.

I still have not seen any FSF general future development direction,
linux-nat.c is IMO obsolete already, at least due to FSF gdbserver.  OK to
post some patches to run in remote mode during default "run" etc. commands?


Thanks,
Jan