This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Incorrect breakpoint address w no stabs
- From: Daniel Jacobowitz <drow at false dot org>
- To: Michael Eager <eager at eagercon dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 1 Oct 2006 14:16:09 -0400
- Subject: Re: Incorrect breakpoint address w no stabs
- References: <451FFF24.3010201@eagercon.com>
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