From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23915 invoked by alias); 31 Aug 2010 10:46:50 -0000 Received: (qmail 23903 invoked by uid 22791); 31 Aug 2010 10:46:48 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Aug 2010 10:46:39 +0000 Received: (qmail 31247 invoked from network); 31 Aug 2010 10:46:37 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Aug 2010 10:46:37 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: [0/9]#2 Fix lost siginfo_t Date: Tue, 31 Aug 2010 10:46:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <20100830070955.GA6831@host1.dyn.jankratochvil.net> <201008302050.02945.pedro@codesourcery.com> <20100830201110.GA17151@host1.dyn.jankratochvil.net> In-Reply-To: <20100830201110.GA17151@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008311146.34085.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00544.txt.bz2 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