From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25890 invoked by alias); 17 Nov 2012 08:15:08 -0000 Received: (qmail 25854 invoked by uid 22791); 17 Nov 2012 08:15:06 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Nov 2012 08:14:59 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDM00K00GFSF800@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Sat, 17 Nov 2012 10:14:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDM00K36HKWL530@a-mtaout22.012.net.il>; Sat, 17 Nov 2012 10:14:56 +0200 (IST) Date: Sat, 17 Nov 2012 08:15:00 -0000 From: Eli Zaretskii Subject: Re: [4/10] RFC: unconditionally include signal.h In-reply-to: <20121117012509.GA3234@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, tromey@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83mwyg3au4.fsf@gnu.org> References: <87obiyzns7.fsf@fleche.redhat.com> <87mwyiy8hi.fsf@fleche.redhat.com> <50A6755C.8040607@redhat.com> <20121117012509.GA3234@adacore.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: 2012-11/txt/msg00481.txt.bz2 > Date: Fri, 16 Nov 2012 17:25:09 -0800 > From: Joel Brobecker > Cc: Tom Tromey , gdb-patches@sourceware.org > > > > I think that checking for signal.h is pointless, because gdb already > > > includes it unconditionally in various places -- e.g., utils.c. > > > > It's not pointless in gdbserver. The HAVE_SIGNAL_H checks were added for > > the WinCE port. See fe7cf52e. > > Should we consider using gnulib's signal.h? In 2 out of 3 files in gdb/gdbserver/ that use HAVE_SIGNAL_H, the references to signal facilities are already in code not compiled if USE_WIN32API is defined. So instead of using HAVE_SIGNAL_H, it strikes me as better and more correct to use USE_WIN32API when including signal.h -- this tells more clearly and honestly what is the reason for not including signal.h and on what platforms. The 3rd file (server.c) could use the same condition for including signal.h -- the rest of the code that needs signals is carefully conditioned on the respective signals being defined. By contrast, gnulib's signal.h defines gobs of functions and macros that we don't necessarily need, and could potentially mean more trouble for WinCE, because (AFAIK) that platform is not supported by gnulib anyway.