symtab.c change breaks assembly lang debugging

symtab.c change breaks assembly lang debugging

[Michael Snyder]

Jim, 

I presume the change below was meant as an optimization, but it's
based on a false assumption -- that you can't have line numbers
if you don't have block symbols.  That premise is untrue if you
are debugging assembly language source, where the assembler emits
line syms but not block syms.  This change breaks the test case
for assembly source debugging, gdb.asm/asm-source.exp.

You would not have noticed, because that test only works on a few
targets right now (d10v being one of them).

	Patch from Peter Schauer:

	* symtab.c (find_pc_sect_line): If we can't find the function
	containing PC, we certainly won't have line number information for
	that location, so return zero immediately.

Michael

Re: symtab.c change breaks assembly lang debugging

[Daniel Jacobowitz]

On Fri, Nov 16, 2001 at 12:15:07PM -0800, Michael Snyder wrote:
> 
> Jim, 
> 
> I presume the change below was meant as an optimization, but it's
> based on a false assumption -- that you can't have line numbers
> if you don't have block symbols.  That premise is untrue if you
> are debugging assembly language source, where the assembler emits
> line syms but not block syms.  This change breaks the test case
> for assembly source debugging, gdb.asm/asm-source.exp.
> 
> You would not have noticed, because that test only works on a few
> targets right now (d10v being one of them).
> 
> 	Patch from Peter Schauer:
> 
> 	* symtab.c (find_pc_sect_line): If we can't find the function
> 	containing PC, we certainly won't have line number information for
> 	that location, so return zero immediately.

<sigh>

OK, I should have thought of that.  The problem is that this almost
always indicates a lack of debugging information, and GDB historically
copes very badly with not having any debugging information available. 
Aside from Jim's address range cleanups, which are certainly a good
solution for the cases they can handle, I don't know what to do about
this.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: symtab.c change breaks assembly lang debugging

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Fri, Nov 16, 2001 at 12:15:07PM -0800, Michael Snyder wrote:
> >
> > Jim,
> >
> > I presume the change below was meant as an optimization, but it's
> > based on a false assumption -- that you can't have line numbers
> > if you don't have block symbols.  That premise is untrue if you
> > are debugging assembly language source, where the assembler emits
> > line syms but not block syms.  This change breaks the test case
> > for assembly source debugging, gdb.asm/asm-source.exp.
> >
> > You would not have noticed, because that test only works on a few
> > targets right now (d10v being one of them).
> >
> >       Patch from Peter Schauer:
> >
> >       * symtab.c (find_pc_sect_line): If we can't find the function
> >       containing PC, we certainly won't have line number information for
> >       that location, so return zero immediately.
> 
> <sigh>
> 
> OK, I should have thought of that.  The problem is that this almost
> always indicates a lack of debugging information, and GDB historically
> copes very badly with not having any debugging information available.
> Aside from Jim's address range cleanups, which are certainly a good
> solution for the cases they can handle, I don't know what to do about
> this.

What need are you trying to address?  Is it, as I surmised, an optimization?
And if so, can we take it out until we think of a better way to do it?

Michael

Re: symtab.c change breaks assembly lang debugging

[Daniel Jacobowitz]

On Fri, Nov 16, 2001 at 02:03:14PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Fri, Nov 16, 2001 at 12:15:07PM -0800, Michael Snyder wrote:
> > >
> > > Jim,
> > >
> > > I presume the change below was meant as an optimization, but it's
> > > based on a false assumption -- that you can't have line numbers
> > > if you don't have block symbols.  That premise is untrue if you
> > > are debugging assembly language source, where the assembler emits
> > > line syms but not block syms.  This change breaks the test case
> > > for assembly source debugging, gdb.asm/asm-source.exp.
> > >
> > > You would not have noticed, because that test only works on a few
> > > targets right now (d10v being one of them).
> > >
> > >       Patch from Peter Schauer:
> > >
> > >       * symtab.c (find_pc_sect_line): If we can't find the function
> > >       containing PC, we certainly won't have line number information for
> > >       that location, so return zero immediately.
> > 
> > <sigh>
> > 
> > OK, I should have thought of that.  The problem is that this almost
> > always indicates a lack of debugging information, and GDB historically
> > copes very badly with not having any debugging information available.
> > Aside from Jim's address range cleanups, which are certainly a good
> > solution for the cases they can handle, I don't know what to do about
> > this.
> 
> What need are you trying to address?  Is it, as I surmised, an optimization?
> And if so, can we take it out until we think of a better way to do it?

No, it isn't an optimization.  It was meant to be a sanity check.

In the presence of stabs, and multiple code sections, the address
ranges for a symtab become invalid.  Suppose that you have libstdc++
with stabs, and a program with no debug info.  Suppose you try to
breakpoint at main.  Libstdc++'s objects have a start address before
main, because it is linked first, but the code is not in that location. 
It's up in the linkonce sections, after main, because *(.text) is first
in the linker script.

We call find_pc_sect_line, and it tells us that the "line" for main is
in libstdc++.  So the breakpoint gets set at the beginning of that
"line" - in libstdc++!  Not useful.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer