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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 30 Aug 2010 22:11:10 +0200
> From: 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?

That seems rather backwards.  If gdbserver works so well, the
linux-nat.c code should be able to work even better.

I fear that it's time for another rewrite of linux-nat.c.  I think I
started lin-lwp.c back in the Linux 2.2 days, when supporting Linux
2.0 was still very much alive and needed to be supported.  Support for
debugging threads was minimal in 2.2 and pretty much non-existent in
2.0.  That code was a horrible horrible hack, and the current code is
just hacks stacked on hack stacked on hacks on top of that.  It is
time to drop support for threads on ancient systems and the old glibc
threads library that goes with them.