Re: [RFC] Python Finish Breakpoints

[Kevin Pouget <kevin.pouget@gmail.com>]

On Wed, Jan 4, 2012 at 3:49 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Kevin Pouget wrote:
>
>>       * gdb.python/py-finish-breakpoint2.cc: New file.
>>       * gdb.python/py-finish-breakpoint2.exp: New file.
>>       * gdb.python/py-finish-breakpoint2.py: New file.
>
> I'm seeing those fail on various platforms (i386, ppc, ppc64):
> FAIL: gdb.python/py-finish-breakpoint2.exp: check FinishBreakpoint in catch()
> FAIL: gdb.python/py-finish-breakpoint2.exp: check finish BP removal
> FAIL: gdb.python/py-finish-breakpoint2.exp: continue to second exception
> FAIL: gdb.python/py-finish-breakpoint2.exp: set FinishBP after the exception
>
> However in other cases the test succeeds -- this appears to be related to
> the particular compiler version that's being used.
>
> The problem is that the finish-breakpoint mechanism sets a breakpoint on
> the regular return address of the current frame, i.e. the instruction
> where the "call" instruction would return normally.  However, when an
> exception is thrown and then caught, execution continues at a different
> call site (in the catch block).  There's now two possibilities:
>
>  try
>    {
>      throw_exception_1 (10);
>    }
>  catch (const int *e)
>    {
>        std::cerr << "Exception #" << *e << std::endl;
>    }
>  i += 1; /* Break after exception 1.  */
>
>
> A) The instruction immediately following the "call" instruction to
>   throw_exception_1 is actually already one of the instructions used
>   to implement the "i += 1" line, and code flow after executing the
>   catch block branches back to that location.  I.e. we have a call
>   graph along the lines of:
>
>   [...]
>       call throw_exception_1 (10)  [ set up catch block at Lc ]
>   Lx: compute i += 1
>   [...]
>
>   Lc: call std:cerr << ...
>       goto Lx
>
>  and the finish breakpoint gets set just at label Lx, and it will
>  get hit both after a regular return and after an exception.
>
> B) The instruction immediately following the "call" instruction
>   is still part of the (clean up after the) call, or some other
>   code flow instruction, and the instructions used to implement
>   "i += 1" are elsewhere.  I.e. the call graph looks more like:
>
>   [...]
>       call throw_exception_1 (10)  [ set up catch block at Lc ]
>   Lx: goto Ly
>
>   Lc: call std:cerr <<< ...
>
>   Ly: compute i += 1
>   [...]
>
>   In this case the finish breakpoint gets set at Lx, which *never*
>   gets executed after an exception.
>
>
> It seems to me that current GDB code does not (even attempt to) properly
> handle the "finish" command and/or the new finish-breakpoint capability
> in the presence of exceptions.  Note that even in case A) above, where
> the finish breakpoint does hit, it arguably hits in the wrong location:
> at the "finish" of the throw_exception_1 line, execution continues *in
> the catch block*, so we should stop at the start of the catch block
> instead of after it has completed.
>
> Am I missing some piece of GDB code that attempts to handle this, and
> is just malfunctioning?  It would certainly be good to properly support
> this feature, but until we do, I'd suggest this test case should be
> disabled ...

Hello,

thanks for spotting and explaining this bug

I can say at least that there is no code to handle this situation in
my patch. One thing I wonder is what's the situation C which passes
the test in my environment ? (x86_64)

My knowledge about C++ is quite limited, but based on your
descriptions, a proper support would involve another breakpoint, set
at Lc, to disable the FinishBreakpoint ... but I'm not sure how
computable this Lc is.

I'll let Tom answer about what to do with the testsuite.


Thanks,

Kevin