From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14063 invoked by alias); 20 Feb 2013 15:56:23 -0000 Received: (qmail 14037 invoked by uid 22791); 20 Feb 2013 15:56:21 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,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; Wed, 20 Feb 2013 15:56:08 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFu6T2013267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 10:56:06 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFu4Qt005052; Wed, 20 Feb 2013 10:56:05 -0500 Message-ID: <5124F214.7020506@redhat.com> Date: Wed, 20 Feb 2013 15:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jan Kratochvil CC: Philippe Waroquiers , gdb-patches@sourceware.org Subject: Re: [patch+NEWS] Avoid false valgrind warnings on linux_ptrace_test_ret_to_nx References: <20130220140520.GA10822@host2.jankratochvil.net> <5124E66D.3060606@redhat.com> <20130220152331.GA16617@host2.jankratochvil.net> In-Reply-To: <20130220152331.GA16617@host2.jankratochvil.net> 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: 2013-02/txt/msg00535.txt.bz2 On 02/20/2013 03:23 PM, Jan Kratochvil wrote: >> I assumed there'd be a reason for the more complete test, >> instead of a simpler and unconditional >> AC_CHECK_HEADERS(valgrind/valgrind.h) and then just >> >> #ifdef RUNNING_ON_VALGRIND >> if (RUNNING_ON_VALGRIND) >> return; >> #endif >> >> As in, you had found that older valgrind/valgrind.h's didn't >> have that RUNNING_ON_VALGRIND macro. > > I haven't found such valgrind. The reason is there could be a broken > valgrind.h include file installed. As GDB built before not depending on such > file in the past and now it would break it would be a regression. > > Or is somewhere a rule what should and what should not be tested by configure? Hmm. I don't see how I can reply to that with a one liner, so apologies in advance for the long text. The basic configure "rule" is test for features you need. There's no way to be more strict and more than guidance. Case by case judgment needs to be applied. However, one unwritten rule (not just GDB's) that applies more broadly than configure things is to not overengineer things, do the minimal necessary, and worry only about unknown problems if they turn out to be real problems. The applied example of that being the general rule would be that we don't have autoconf checks for every function and macro we use from all the headers we include. From that perspective, the simpler approach would be better, as we'd have less code to maintain, and fewer configure knobs to document and explain to users. To break the build, either the header would be completely broken, and would break every program that includes it (unlikely, used by several programs in a distro), or, RUNNING_ON_VALGRIND would be broken (unlikely, likewise), or the header would use some symbol that would conflict with the other headers the linux-ptrace.c file includes before valgrind.h, which is possible, but is not something that is checked by the new autoconf check, so the most likely (IMO) scenario would be broken anyway. That said, I really don't intend to argue. -- Pedro Alves