From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14599 invoked by alias); 14 Jan 2004 15:16:22 -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 14592 invoked from network); 14 Jan 2004 15:16:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 14 Jan 2004 15:16:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Agmkl-0001gv-Nm; Wed, 14 Jan 2004 10:16:19 -0500 Date: Wed, 14 Jan 2004 15:16:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc/testsuite] Test GDB on not-so-little core files Message-ID: <20040114151619.GA6374@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040114145701.9034A4B104@berman.michael-chastain.com> <40055B49.70003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40055B49.70003@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00374.txt.bz2 On Wed, Jan 14, 2004 at 10:07:53AM -0500, Andrew Cagney wrote: > >>testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp > >>completed in 183 seconds > >>testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds > > > > > >Figures prove: Linux dumps core faster! :) > > > >Part of the difference is that I'm using an NFS file system. > > Nope. I'm using NFS on a weasly little 450mhz P2. > > >But a lot of it may be sparse file support in Linux. > > Yep. While sparse file support is a standard part of UFS, it appears > that only the Linux Kernel thought to exploit it when writing the core file! There are two things that make me really nervous about this test. One of them is systems with bad out-of-memory behavior, and the other is systems that don't dump sparse corefiles. That's some serious pounding we'll be handing out... Also, you will get very different results even on GNU/Linux depending on your kernel's overcommit behavior. It may refuse to allocate more VM space than you have RAM if strict overcommit mode is enabled. On a minor note, your test for the maximum value of a size_t is unportable. C does not define signed overflow, so a future version of GCC (possibly 3.4 or even 3.3 already, I don't know) can assume that the loop never terminates and remove the rest of the program as unreachable. I doubt it'll do that when not optimizing. > >I can't comment on the program itself right now, maybe later. > > Hmm, can you think of an efficient way of soaking up most of the stack > ...? :-) On GNU/Linux, alloca() proved to be useless :-( The best you're likely to get is recursively calling a function with a, say, 4K frame. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer