debugging "break point" in optimized code?

[John Fine]

Reza Roboubi wrote:
> What does a breakpoint mean anyway when code is optimized?
>
>
A breakpoint is still a breakpoint.  Even when optimized, -g on compile 
and link will still put in line number information that identifies a 
source file / line number for each machine language line.  That 
information just isn't as accurate as it would be in non optimized code.

1) After optimization, a single machine language instruction might be 
parts of several source lines.  So no one source line could be a 
correctly identified as THE source line of that machine language 
instruction.
So far as I understand, the process doesn't try to identify multiple 
source lines for one machine language instruction.  I don't know if the 
file formats would even support that.  If it did, that would present an 
interesting set of challenges and opportunities for debuggers and profilers.

2) Sometimes GCC confuses itself in the optimization process, so a 
machine language instruction unambiguously belongs to a single source 
line and GCC identifies it as belonging to a different source line.

In unoptimized code, there tends to be a small contiguous set of 
instructions associated with each source line.  So setting a breakpoint 
on a source line obviously means setting a breakpoint on the first 
instruction of that contiguous set.

In optimized code, the source line might be instantiated multiple times 
and each instantiation might be a set of discontiguous instructions.  
What should setting a breakpoint there mean?  (If you really want the 
answer, this discussion should be in a gdb mailing list, not a gcc 
mailing list).  Someone doing source level debugging would probably like 
it to mean something that causes a break on any transition from code 
that is not part of that line to code that is part of that line.  After 
that, things get even more complex.  What does it mean to proceed from 
such a breakpoint?  Certainly not stop at the next instruction if that 
is still part of the same line.  The one source breakpoint should be 
many instruction breakpoints.  When you proceed, which of them are 
turned off and for how long?

The Microsoft Visual Studio debugger comes closer than GDB to meeting 
naive expectations about source level debugging as discussed above.  But 
it doesn't come close enough to make such debugging practical.

I debug only optimized code.  (Not by intent, it just works out that 
way).  I always use a split view of source and disassembly.  I almost 
never set breakpoints on source lines.  There is too much risk the 
breakpoint would be somewhere distant from where one would reasonably 
expect.  I look at the source code, then I set breakpoints in the 
disassembly.