From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26954 invoked by alias); 3 Oct 2006 02:38:33 -0000 Received: (qmail 26930 invoked by uid 22791); 3 Oct 2006 02:38:32 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Oct 2006 02:38:29 +0000 Received: from [192.168.20.7] (209-128-106-254.bayarea.net [209.128.106.254]) (authenticated bits=0) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k932cNLT018714; Mon, 2 Oct 2006 19:38:24 -0700 Message-ID: <4521CD1F.20609@eagercon.com> Date: Tue, 03 Oct 2006 02:38:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: Incorrect breakpoint address w no stabs References: <451FFF24.3010201@eagercon.com> <20061001181609.GA5065@nevyn.them.org> In-Reply-To: <20061001181609.GA5065@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00007.txt.bz2 Quick follow-up. This problem doesn't happen if all object files use DWARF or no debugging. If the executable has mixed stabs/DWARF, then the problem shows up. I don't need to support mixed debugging formats after all, so your initial advice to avoid stabs is the clear winner. I submitted a bug report to the GDB bug system. It didn't tell me the bug number, so go figure. Thanks for the help. Daniel Jacobowitz wrote: > 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. > -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077