From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19196 invoked by alias); 15 Sep 2004 17:20:33 -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 19140 invoked from network); 15 Sep 2004 17:20:32 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sourceware.org with SMTP; 15 Sep 2004 17:20:32 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1C7dSE-0002tX-00; Wed, 15 Sep 2004 13:20:26 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id CABF44B102; Wed, 15 Sep 2004 13:20:35 -0400 (EDT) Date: Wed, 15 Sep 2004 17:20:00 -0000 From: Michael Chastain To: brobecker@gnat.com Subject: Re: [RFA/mips] mips32 frame code simplification... Cc: gdb-patches@sources.redhat.com Message-ID: <414879E3.nailB7Z1MJFFM@mindspring.com> References: <20040915062611.GD1622@gnat.com> <414844E4.nail2UE22SZGZ@mindspring.com> <20040915162937.GU5843@gnat.com> In-Reply-To: <20040915162937.GU5843@gnat.com> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00255.txt.bz2 Joel Brobecker writes: > I don't think that's the problem. I get an infinite loop inside GDB > itself (backtracing from a signal handler I think), and that causes > the expect/dejagnu buffer to get full. How about: set backtrace limit 1000 That would look good in default_gdb_start and mi_gdb_start. However a backtrace limit of 1000 would still overflow the 20000-character buffer. Also I've heard that "set backtrace limit" has a bug these days. We could also change the individual "backtrace" and "bt" calls to "backtrace 100". That's simpler and more effective, but it fixes just one nit at a time. > And apparently, this just disables dejagnu for the rest of the run > (can't spawn the compiler nor the debugger anymore for instance). > Maybe there is a way of flushing that buffer when we do a gdb_exit? I don't know enough about expect to get into that area. :(