From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25194 invoked by alias); 1 Oct 2006 20:50:33 -0000 Received: (qmail 25185 invoked by uid 22791); 1 Oct 2006 20:50: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; Sun, 01 Oct 2006 20:50:30 +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 k91KoGdk025205; Sun, 1 Oct 2006 13:50:17 -0700 Message-ID: <45202A0B.9080004@eagercon.com> Date: Sun, 01 Oct 2006 20:50: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/msg00002.txt.bz2 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 :-) Well, that's the advice I would give myself. :-) > What version of GDB are you working with? 6.5.0. > 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... The logic (or should I say, flow of control) is really quite convoluted. Just my opinion. >> 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. I'll see if I can use that. > 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. But if it isn't reliable, then gdb shouldn't be using it to find line tables. >> 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. Apparently there is a SLINE for offset zero in a function. I'd thought that the first SLINE was at the first line of the function, which is after the prologue. >> 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. So, somehow, in most(?) cases, gdb is finding the right address. > 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. The former sounds like a good idea. One problem seems to be that breakpoint depends on a sal. find_pc_sect_line looks like it does the best it can, given its assumptions: that each object file has a symtab and line table. But that's not always the case. minsym_found calls find_pc_sect_line. I don't see why that is needed. > Do you have the N_FUN end stabs? I can't see how this could blow up > the way you described, if you did. Nope. No end N_FUN. No fun. ;-> What breaks if I simply remove the "cleanup" code at the end of read_dbx_symtab? -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077