This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Incorrect breakpoint address w no stabs


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]