From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6302 invoked by alias); 15 Jan 2004 19:13:41 -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 6293 invoked from network); 15 Jan 2004 19:13:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Jan 2004 19:13:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AhCvy-00022L-0k; Thu, 15 Jan 2004 14:13:38 -0500 Date: Thu, 15 Jan 2004 19:13:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc/testsuite] Test GDB on not-so-little core files Message-ID: <20040115191337.GA7759@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040114145701.9034A4B104@berman.michael-chastain.com> <40055B49.70003@redhat.com> <20040114151619.GA6374@nevyn.them.org> <4006E56E.6010803@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4006E56E.6010803@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00393.txt.bz2 On Thu, Jan 15, 2004 at 02:09:34PM -0500, Andrew Cagney wrote: > >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. > > That would unfortunatly defeat the current technique of creating a very > large but very sparse core file. I'll see what I can cook up. If you don't touch the stack at least once in a while, you will get segfaults without first allocating stack space, on many platforms; they'll look at how far down the stack you went and if you've moved past the limit into data, they won't bother to grow the stack. I'm not sure it's possible to get stack pages allocated that aren't backed by allocated memory... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer