Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64)

[Daniel Berlin <dan at cgsoftware dot com>]

Daniel Berlin <dan@cgsoftware.com> writes:

> Joern Rennecke <amylaar@cambridge.redhat.com> writes:
> 
> > > In the case of heavily intermingled code, the line number info may
> > > look like (i've omitted is_stmt, basic_block, and other registers, for
> > > simplicity):
> > > 
> > > Line advance            Address advance
> > > 0                       1
> > > -1                      1
> > > 2                       1
> > > -1                      1
> > > etc
> > 
> > So that's the way gdb handles it right now.  Which can mean that
> > optimized code is so tedious to debug for some applications and targets
> > that you try to avoid it at all costs.  Not what I'd call 'not being able
> > to tell the difference'.
> 
> Err, what are you talking about?
> I mean this is what the debug info says, not what gdb *does* (or will
> do).

Let me expand.

What GDB does is take this, and throw it all away.
It says a line can have a pc range, but it can't be discontiguous.
So we can't actually follow what really happens, we just go to the
source line past the end of the range for that line, etc.
If we did something like the above, we'd at least always be on the
right line when you type step or next (step would skip around as the
line we are on decrements or advances, but it'd be correct. next would
do what it says, and go to the next source line. In other words, next
just wouldn't follow negative line advances).

--Dan

-- 
"I saw a bank that said "24 Hour Banking", but I don't have that
much time.
"-Steven Wright