From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23544 invoked by alias); 1 Oct 2006 18:16:17 -0000 Received: (qmail 23536 invoked by uid 22791); 1 Oct 2006 18:16:16 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 01 Oct 2006 18:16:13 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GU5rF-0001Up-Pm; Sun, 01 Oct 2006 14:16:09 -0400 Date: Sun, 01 Oct 2006 18:16:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: gdb@sources.redhat.com Subject: Re: Incorrect breakpoint address w no stabs Message-ID: <20061001181609.GA5065@nevyn.them.org> Mail-Followup-To: Michael Eager , gdb@sources.redhat.com References: <451FFF24.3010201@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451FFF24.3010201@eagercon.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00001.txt.bz2 I'm going to do some guesswork here. The very first response to any question involving stabs is the usual one: don't. Use DWARF-2 instead. But given who's asking the question, I assume you've already considered that option :-) What version of GDB are you working with? On Sun, Oct 01, 2006 at 10:47:16AM -0700, Michael Eager wrote: > When gdb gets the symbol __fini, it finds the correct > address in lookup_minimal_symbol. In find_pc_sect_psymtab, > it locates the partial symbol which contains the address. > In parse_breakpoint_sals it searches the line table for > that psym to find the line which supposedly contains the > address. There have been a lot of problems with this code over the years... > But the range of addresses for the psym is incorrect, > so the wrong psym has been selected for the line search. > At the end of read_dbx_symtab, the routine has "cleaned > up" the psym for the last object file with debug info > by setting psym->texthigh to be the last location in > the section. That range is incorrect, and in my test > case, includes the .o which contains __fini. Texthigh > should be set to the end of the object file with stabs. > > First root cause: read_dbx_symtab does not set the > end address for a psym correctly. Is there any way > to correctly locate the end of the object file? Or > the end of a function containing stabs? (I don't think > that there is any way to identify the end of the last > .o with stabs.) Is the code at the end of read_dbx_symtab > really needed? Stabs normally do not mark the end of functions. There's a GNU extension for this when using gcc -gstabs+ (see dbxout_function_end); there will be an N_FUN with an empty name and it will mark the size of the function as its value. GDB knows how to parse these. The current use of text_size doesn't make any sense to me. In any case texthigh in psymtabs is sometimes conservative and we can't expect it to be reliable. > Second root cause: gdb has translated a symbol to > an address, which it gets right. It goes on to try to > translate the address to a line number, which it gets > incorrect. IMO, that second translation doesn't seem > necessary. There's no reason that I can think of to try > to convert from a symbol to a line number. The symbol is > the location for the break (modulo stepping over prologue > code). I'd also guess that most symbols are not in > ranges covered by a line table. Not sure what you mean; almost every symbol is in a range covered by a line table. Do you mean specifically in minsym_found? That does seem strange. > It would seem that this problem would make it impossible > to place a breakpoint at any function which was compiled > without -g. I'm not sure that this is actually the > case, so there must be something else going on. If this > were the case, I think that there would be many bug > reports about the problem. It is not the case. There's two things that could be changed: we could avoid looking up line numbers for minimal symbols, or we could make find_pc_sect_line do something saner. Do you have the N_FUN end stabs? I can't see how this could blow up the way you described, if you did. -- Daniel Jacobowitz CodeSourcery