From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27745 invoked by alias); 13 Mar 2004 02:08:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27599 invoked from network); 13 Mar 2004 02:08:10 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sources.redhat.com with SMTP; 13 Mar 2004 02:08:10 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1B1yZK-0000oo-00; Fri, 12 Mar 2004 21:08:06 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 511364B104; Fri, 12 Mar 2004 21:07:58 -0500 (EST) To: brobecker@gnat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] Some feedback about bigcore.exp... Message-ID: <20040313020758.511364B104@berman.michael-chastain.com> Date: Sat, 13 Mar 2004 02:08:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-03.o/txt/msg00297.txt Message-ID: <20040313020800.pFPTAZWOALyABwK40yT7f5kKJm3AXmm0bqDCmoeIQTo@z> My thoughts ... It's really more of a per-site thing, which to me means an environment variable. I know the dejagnu way would be to set a variable in site.exp but I really prefer to work with environment variables. The default is to run the test in order to flush out more bugs on more architectures but perhaps we could have an easy way to suppress this test and then document that way. It's tough to run a regression test suite when one of the 300 test scripts bangs so many operating systems so hard. The core file should not fill up the disk as long as the operating system and the file system dump core files as sparse files. (Cheat sheet: think of a file as an array of blocks. For a "sparse file", the file system does not store blocks which are all 0's. All the system calls like read(2) and write(2) work normally but there are less blocks needed on the disk than the size of the file.) I'm running red hat linux 8 with kernel 2.4.8-14 on an ext3 file system and my core files are sparse. What kernel/file-system do you have where the core files actually take up that much space? I wish there were a portable way to compress sparse files quickly and easily. I'm using "tar cSf ..." to manage these files followed by bzip2 but that is gnu-specific. Michael C