[Bug python/27247] FAIL: gdb.python/py-finish-breakpoint2.exp: check FinishBreakpoint in catch()

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27247

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Relevant bit of the source:
...
    36    try
    37      {
    38        throw_exception_1 (10);
    39      }
    40    catch (const int *e)
    41      {
    42          std::cerr << "Exception #" << *e << std::endl;
    43      }
    44    i += 1; /* Break after exception 1.  */
...

The -m64 scenario in more detail:
- the test-case runs to throw_exception_1.
- it installs a FinishBreakpoint, which is a temporary breakpoint set at the
  return address of a frame.
- for -m64, that address is:
    400c47:       83 45 e4 01             addl   $0x1,-0x1c(%rbp)
  which corresponds the "i += 1 at line 44"
- the test-case then continues
- an exception is throw in throw_execution_1
- the exception is caught at line 40, and a message is printed
- line 44 is executed, and the FinishBreakpoint triggers.

With -m32, we have instead:
- the address where the finish breakpoint is set is:
    8048a0a:       83 c4 10                add    $0x10,%esp
  which is the lasn insn generated for the call at line 38
- the test-case continues
- an exception is throw in throw_execution_1
- consequently, the FinishBreakpoint is not triggered.

In conclusion, the test works by accident for -m64, because the first insn
after the call to throw_exception_1 is also the first insn after the try.
And that just happens to be not the case for -m32.

[ This was also noted by Andrew here (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ):
...
A further issue is that the testing for FinishBreakpoints, in
gdb/testsuite/gdb.python/py-finish-breakpoint2.exp, the test action titled
"check FinishBreakpoint in catch()" expects the "stop" method to fire rather
than the "out_of_scope" method, this is due to the generated code (on x86 and
maybe other targets), the first breakpoint we hit after throwing the exception
happens to be the finish breakpoint, however this is not guaranteed, and means
that (a) the test does not match the documentation, and (b) the test is
platform specific.
... ]

-- 
You are receiving this mail because:
You are on the CC list for the bug.