Incorrect breakpoint address w no stabs

Incorrect breakpoint address w no stabs

[Michael Eager]

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

Re: Incorrect breakpoint address w no stabs

[Daniel Jacobowitz]

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

Re: Incorrect breakpoint address w no stabs

[Michael Eager]

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

Re: Incorrect breakpoint address w no stabs

[Daniel Jacobowitz]

On Sun, Oct 01, 2006 at 01:50:19PM -0700, Michael Eager wrote:
> What breaks if I simply remove the "cleanup" code at the
> end of read_dbx_symtab?

I haven't the foggiest.  You definitely can't remove the call to
end_psymtab; you're going to lose the last partial symtab in the file.
There might be something smarter you can do for the final address
(adding text_size seems excessive).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Incorrect breakpoint address w no stabs

[Michael Eager]

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

Re: Incorrect breakpoint address w no stabs

[Michael Snyder]

On Mon, 2006-10-02 at 19:38 -0700, Michael Eager wrote:
> 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.

What about if all object files use stabs?

Re: Incorrect breakpoint address w no stabs

[Michael Eager]

Michael Snyder wrote:
> On Mon, 2006-10-02 at 19:38 -0700, Michael Eager wrote:
>> 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.
> 
> What about if all object files use stabs?

There's almost always assembly files (without stabs) which
are linked after the rest of the code.  Breakpoints at
symbols in those files will be incorrect.


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