3 Replies Latest reply on Feb 4, 2019 5:58 AM by ilg

    Optimisation preventing breakpoint to be hit

    brendansimon

      I have the following simple program to test GNU MCU Eclipse.  It works ok with optimizations turned off (-O0).  The test is to put a break point on the return statement, click go/run/continue button, and check the result of `ret` when the debugger breakpoint is hit.

       

      int main( void )

      {

        int ret = 0;

       

        for ( int i = 0 ; i < 10 ; i++ )

        {

          ret += 1;

        }

       

        return ret;

      }

       

       

      If I enable "optimize for debug (-Og)" then the break point is never hit and it jumps straight to `_exit()`.  My guess is that the compiler knows the result is already in a register used for return values and bypasses the `return ret` line altogether.  I feel this is a bug as the code as it is written suggests that the `return ret` line should always be hit and exit the function at that one point.  It may be arguable with aggressive optimization that the compiler is allowed to do that, but I don't think it should (not with -Og at least).

       

      If I change `int ret = 0;` to `volatile int ret = 0;` then the breakpoint is hit.

       

      Is this an issue worth reporting on the GNU MCU Eclipse issue tracker, or is it a GCC issue to be reported upstream somewhere?

      Thanks, Brendan.

       

       

       

      • Reply
        • Re: Optimisation preventing breakpoint to be hit
          ilg

          > ... It works ok with optimizations turned off (-O0). ... If I enable "optimize for debug (-Og)" then the break point is never hit

           

          the debugger is guaranteed to work only with -O0.

           

          -Og sometimes works, sometimes not. if you enable LTO, the code is so much reordered, that debug is almost impossible on anything but -O0.

           

          Eclipse and gdb have still lots of bugs, but this is not one of them.

            • Re: Optimisation preventing breakpoint to be hit
              brendansimon

              I can accept that using LTO can make things hard to debug and be hard (impossible?) for debuggers to implement reliable debugging.

               

              However, selecting optimizations for debugging only (-Og, no LTO), should by definition be debuggable ... surely?  To me that means being able to hit breakpoints, especially if it is on the only return statement at the end of a function.  Why have -Og at all if the resultant code is not guaranteed to be debuggable?