From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13464 invoked by alias); 8 Sep 2011 14:15:55 -0000 Received: (qmail 13454 invoked by uid 22791); 8 Sep 2011 14:15:53 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Sep 2011 14:15:20 +0000 Received: from nat-dem.mentorg.com ([195.212.93.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R1fNv-0002m9-Ag from pedro_alves@mentor.com ; Thu, 08 Sep 2011 07:15:19 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by eu2-mail.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 16:15:17 +0200 From: Pedro Alves To: Jan Kratochvil Subject: Re: Running testsuite with /proc/sys/kernel/core_uses_pid set, avoiding leaving core dump files behind Date: Thu, 08 Sep 2011 14:34:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201109071718.38581.pedro@codesourcery.com> <20110908130833.GA10013@host1.jankratochvil.net> In-Reply-To: <20110908130833.GA10013@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109081515.15752.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: 2011-09/txt/msg00133.txt.bz2 On Thursday 08 September 2011 14:08:33, Jan Kratochvil wrote: > On Wed, 07 Sep 2011 18:18:38 +0200, Pedro Alves wrote: > > I'm fixing this by making the tests look for core.PID as well. > > Do you have anything against using lib/gdb.exp core_find instead? Nothing personal, no. :-) core_find is meant for a different scenario. core_find runs a program that dumps core by itself, and such produced core file is then used on subsequent gdb tests, as the inferior to debug. The annota*.exp tests run a program that doesn't normally crash, debug it normally (do some next/steps, etc., with annotations enabled), and then force a signal on the inferior we know is not t handled ("(gdb) signal SIGTRAP"). The purpose of the test is not to generate the core dump per se, but to check the annotations around sending a signal that is not handled by the program. The core itself it totally uninteresting, and is a byproduct. If you were investigating a annota*.exp fail, you'd not need the core dump for anything. On light of that, do you agree? > > Anyway, I don't supposed there are any objections to this > > patch? > > While I agree that leaving a bunch of "anonymous" core files is definitely bad > the advantage of lib/gdb.exp core_find is that it keeps the intermediate files > for later problems investigations - identifiable with names "$binfile.core". Right, that's useful when we have tests that used the core as inferior, so keeping it around is useful, as that way you still have the exact same inferior handy to be able to reproduce the crash. But that's not the case of these tests. -- Pedro Alves