From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17254 invoked by alias); 22 Feb 2002 19:52:26 -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 17169 invoked from network); 22 Feb 2002 19:52:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 22 Feb 2002 19:52:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16eLjz-0005lf-00; Fri, 22 Feb 2002 14:52:23 -0500 Date: Fri, 22 Feb 2002 11:52:00 -0000 From: Daniel Jacobowitz To: Richard.Earnshaw@arm.com Cc: gdb-patches@sources.redhat.com Subject: Re: Infinite loop in make_cv_type Message-ID: <20020222145223.A22015@nevyn.them.org> Mail-Followup-To: Richard.Earnshaw@arm.com, gdb-patches@sources.redhat.com References: <200202221906.TAA07621@cam-mail2.cambridge.arm.com> <200202221944.TAA09969@cam-mail2.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202221944.TAA09969@cam-mail2.cambridge.arm.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00630.txt.bz2 On Fri, Feb 22, 2002 at 07:44:44PM +0000, Richard Earnshaw wrote: > > > Any suggestions as to how the stabs reader might be getting ahead of > > itself? Is there another function that might be returning the stabs > > string? I don't think dbx_next_symbol_text has ever returned this > > earlier... > > Dead simple really. The stabs on the ARM are broken into very short > strings for historical reasons (there was once an assembler that couldn't > cope with stabs strings of more than about 100 characters). We are simply > running off the end of a stabs string without calling STABS_CONTINUE. > Thus we end up parsing the following string twice: once on the overrun and > the second when dbx_next_symbol_text returns it. > > OK to apply? > > R. > > Richard Earnshaw (rearnsha@arm.com) > > * stabsread.c (read_member_functions): Call STABS_CONTINUE after > skipping a method. > > My fault, it figures. I've never been clear when STABS_CONTINUE is actually necessary. I can't approve it, but this looks good to me. The rest of the problems you found should be fixed, but are not urgent; I'll try to get to gdb/277 in the next few weeks... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer