Incorrect breakpoint address w no stabs

[Michael Eager <eager@eagercon.com>]

I've run into what seems to be the same problem as
http://sourceware.org/ml/gdb/2002-02/msg00055.html

If I set a breakpoint at a label defined in an
assembler routine, say __fini, gdb places the breakpoint
at an incorrect address.

There seem to be two different root causes (if that's
possible) and I'm unclear on the fix for either.

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.

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?

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.

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.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077