This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Incorrect breakpoint address w no stabs
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