From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13719 invoked by alias); 19 Nov 2012 15:05:54 -0000 Received: (qmail 13687 invoked by uid 22791); 19 Nov 2012 15:05:53 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Nov 2012 15:05:21 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAJF5HK5022916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Nov 2012 10:05:18 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAJF5Eh4032565; Mon, 19 Nov 2012 10:05:14 -0500 Message-ID: <50AA4AA9.5090206@redhat.com> Date: Mon, 19 Nov 2012 15:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii CC: Joel Brobecker , tromey@redhat.com, gdb-patches@sourceware.org Subject: Re: [4/10] RFC: unconditionally include signal.h References: <87obiyzns7.fsf@fleche.redhat.com> <87mwyiy8hi.fsf@fleche.redhat.com> <50A6755C.8040607@redhat.com> <20121117012509.GA3234@adacore.com> <83mwyg3au4.fsf@gnu.org> In-Reply-To: <83mwyg3au4.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00500.txt.bz2 On 11/17/2012 08:14 AM, Eli Zaretskii wrote: >> 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. I agree. > > 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. I agree. Unlike non-CE Windows, CE doesn't really have any traces of signal numbers or functions in its C runtime. I still looks to me that guarding common/signals.c's inclusion of signal.h with HAVE_SIGNAL_H describes the real issue in that case better (unless we wanted to resort to platform checks, like #ifdef _WIN32_WCE, which we tend to avoid). Replacing signal.h with a gnulib signal.h replacement that defines signals and kill/signal/etc. from that perspective would kind of miss the point of common/signals.c, which is to map host signals to gdb signals. -- Pedro Alves