Re: Incorrect breakpoint address w no stabs

[Michael Eager <eager@eagercon.com>]

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