Re: [RFC] Python Finish Breakpoints

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Kevin Pouget wrote:
> 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)

Hmm, with C the problem potentially exists as well:

  if (setjmp (env) == 0) /* longjmp caught */
    {
      call_longjmp (&env);
    }
  else
    j += 1; /* after longjmp.  */


The finish breakpoint is set immediately after the call to call_longjmp,
which may or may not coincide with the first instruction of "j += 1".

I guess since the compiler's control flow graph is much simpler as there
are no implicit exception edges (rather, setjmp is a "regular" function
that just happens to "return twice"), it is more likely for GCC to
arrange the resulting assembler in the sequence where everything
appears to work ...

You might be able to force the problem to consistently appear by adding
extra code after call_longjmp, e.g. like so:

  if (setjmp (env) == 0) /* longjmp caught */
    {
      call_longjmp (&env);
      some_other_stuff ();
    }
  else
    j += 1; /* after longjmp.  */


On the other hand, (at least on some platforms), GDB will actively
track calls to longjmp by setting a breakpoint on longjmp and then
stepping through until the destination.  This might give GDB a
chance to notice that the finish breakpoint has gone out of scope
by the longjmp, and trigger the break then.  That would probably
be the best way to implement this feature anyway ...


> 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.

Not very; you could attempt to decode the exception tables, but those
are platform-specific.  It might be preferable to handle "throw"
similar to how we handle "longjmp", see above.


Bye,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com