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

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 30 August 2010 21:11:10, Jan Kratochvil wrote:
> 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.

Ah.  Yeah, gdbserver/linux-low.c does not in fact for a SIGSTOP
out of the inferior and requeues signals like linux-nat.c does.
When an lwp stops with a non-SIGSTOP signal, it just sets the
lwp->stop_expected flag (meaning, there's a SIGSTOP in the kernel
signal queue that is expected, because we put it there), and
leaves the lwp stopped as is.  There are pros and cons in
doing it that way or doing linux-nat.c's way.

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

Sorry.  :-/

> 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?

gdb and gdbserver codebases are different, and each has features not
supported by the other, so, dropping one of them now instantly drops
supported features.

What I have been trying to do over the last couple of years that
I've had the opportunity of working on gdbserver, is progressively make
the codebases converge, design, API, and implementation wise, taking the
ideas from each (gdbserver's target_wait interface, no remote protocol
in the backends, breakpoint canceling, etc.).  If we keep
doing that, eventually, one of the backends will be a superset of the other
(my bets on gdbserver's), and we can then consider sharing code between
them, or even make gdb invoke gdbserver as a separate binary.  Of course,
if someone were to work on doing the conciliation as _main focus_ instead
of piggy backing that on other work that customers actually care for, then
things would move faster...

-- 
Pedro Alves