From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Daniel Berlin Cc: Joern Rennecke , mark@codesourcery.com (Mark Mitchell), wilson@cygnus.com, gcc@gcc.gnu.org Subject: Re: debugging optimized programs (Was: Re: Bootstrap failure of gcc-ss-20010409 in ia64) Date: Wed, 18 Apr 2001 17:18:00 -0000 Message-id: References: <200104182249.f3IMnBD07197@phal.cambridge.redhat.com> X-SW-Source: 2001-04/msg00902.html Daniel Berlin writes: > Joern Rennecke 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