From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24778 invoked by alias); 26 Feb 2013 03:00:38 -0000 Received: (qmail 24769 invoked by uid 22791); 26 Feb 2013 03:00:36 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,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; Tue, 26 Feb 2013 03:00:27 +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 r1Q30KD1016931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Feb 2013 22:00:24 -0500 Received: from host2.jankratochvil.net (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1Q300iu018307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 22:00:06 -0500 Date: Tue, 26 Feb 2013 03:00:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Philippe Waroquiers , gdb-patches@sourceware.org Subject: Re: [patch+NEWS] Avoid false valgrind warnings on linux_ptrace_test_ret_to_nx Message-ID: <20130226025956.GA13814@host2.jankratochvil.net> References: <20130220140520.GA10822@host2.jankratochvil.net> <5124E66D.3060606@redhat.com> <20130220152331.GA16617@host2.jankratochvil.net> <5124F214.7020506@redhat.com> <20130220160808.GA19181@host2.jankratochvil.net> <5125082A.8040901@redhat.com> <20130225143242.GB25286@host2.jankratochvil.net> <512BA904.8080604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512BA904.8080604@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00637.txt.bz2 On Mon, 25 Feb 2013 19:10:12 +0100, Pedro Alves wrote: > as I didn't want to set precedent for adding checks for unknown problems > without reason. It's better to wait for the problems to appear, so at least > our future selves wanting to change this code know what sort of problems to > expect. This contradicts your earlier mail for the same feature: Re: [patch+7.5] Fix assertion fail on PaX gentoo (PR 14564) http://sourceware.org/ml/gdb-patches/2012-09/msg00108.html Message-ID: <504DF20E.102@redhat.com> The linux_test_for_tracefork family of functions seems to warn instead of asserting if something unexpected comes out of ptrace/waitpid. Might be a good idea for this function too? You wrote there first: # It seems like one should be able to make them trigger # by sending a signal to gdb's process group, or "killall gdb" at # the wrong time? E.g., a SIGTERM, a SIGINT, or a SIGSTOP? For this specific part I have to disagree, this does not solve the warning-vs-assert problem, even if SIG* reception does not get handled correctly still bogus warning gets reported. If someone sends SIGTERM/SIGINT then it will kill also GDB process itself so it is not an issue. SIGSTOP should not be a problem as waitpid does not use WSTOPPED there. Just guessing, I have not tried either, though. And by turning it assert -> warning makes the situation only worse (whether it is worse or not is IIUC the subject of disagreement). On assert it gets automatically bugreport by ABRT and a fix gets possibly automatically delivered in several days in a system update. Contrary to it a warning annoys people for a long time before someone finally bugreports it by hand, usually omitting various details needed for a fix so it gets all expensive for user + developer to investigate the problem first. So while it is clear what is better for normal modern systems like Fedora there remains a question what is the direction of upstream GDB. According to your 2012 direction errors should be reported "softly". In your current mail you prefer rather build failure (instread of omitting the feature unsupported by the build machine). While I have discussed here only this specific issue of these two mails this was always an issue with GDB, what should be an internal error vs. warning only in some unexpected cases. > I find the non-x86* argument somewhat compelling. I do still > think the mention of valgrind/valgrind.h here: > > [--with-valgrind was requested but was not found]) > > isn't 100% correct, and will be misleading -- your non-x86* example > failing to build RUNNING_ON_VALGRIND would show that error, though > the header was indeed found. If you don't like the other suggestion for > "support" and you still want to mention the header, then adding a "working" > would be fine with me: > > [--with-valgrind was requested but working was not found]) OK. > (*) - and I wish in commit logs - following Joel's lead, I've > been personally making an effort to push self-contained commit > logs with full change description myself. I normally look up the mail thread around it. It would be great to have some automated tracking of commit vs. its mail (and therefore its mail thread). The longer commit logs are fine but they do not replace the mail thread. Jan