From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29512 invoked by alias); 12 Apr 2002 02:11:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29489 invoked from network); 12 Apr 2002 02:11:31 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Apr 2002 02:11:31 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16vqXP-0000eI-00 for ; Thu, 11 Apr 2002 22:11:43 -0400 Date: Thu, 11 Apr 2002 19:11:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Further problem with 2.95.3 debug info :( Message-ID: <20020411221143.A2000@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00201.txt.bz2 This one isn't as easy as the last stabs fix. Sometimes, apparently, GCC elides the first line number instead of shifting it later. As a result, breakpoints on the function now stop in a yet wronger location. Example: main: .LBB10: pushl %ebp movl %esp,%ebp subl $2044,%esp pushl %edi pushl %esi pushl %ebx .stabn 68,0,90,.LM21-main .LM21: addl $-12,%esp pushl $toplevel call _setjmp addl $16,%esp testl %eax,%eax je .L174 .stabn 68,0,92,.LM22-main .LM22: So we break after the first call to setjmp. Which is, the astute observer notes, inside of an `if'. In this case, it's a not-usually-taken `if' and we stop at the completely wrong time. There's no fixing this with the debug info we have, IMO. GCC 3.0 gets the debug info right and we then handle it correctly. I've no idea what prompts GCC to do which (although it seems to show up more on PowerPC than on i386, I've seen it on both). So, this message is just in case anyone has a brilliant idea for handling this, or to save people a little time on bug reports. The only thing I can think of is to let a prologue scanner hit the panic button and say "no, the prologue really DOES end between lines!". -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer