Bug 16087 - cannot step in catch block after exception is thrown
Summary: cannot step in catch block after exception is thrown
Status: RESOLVED INVALID
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: 7.4
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-25 15:51 UTC by Toma Bilius
Modified: 2013-11-04 09:17 UTC (History)
2 users (show)

See Also:
Host:
Target: arm-elf
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toma Bilius 2013-10-25 15:51:47 UTC
We're using a test application for ARM (cortex a9) compiled with GCC 4.6.3 and thumb2. We use GDB 7.4 to debug the target. We have trouble stepping over the code in a try/catch block. After setting a breakpoint on throw, it is hit but when issuing a next command GDB will just resume execution.

Here's the initial c++ code:
               try
               {
                  throw 4711;             /* GDB Test (cplusplus.cpp,1) */
               }
               catch (int i)              /* GDB Test (cplusplus.cpp,2) */
               {
                  blue::fibonacci(5);     /* GDB Test (cplusplus.cpp,3) */
               }                          /* GDB Test (cplusplus.cpp,9) */

After disassembling we noticed that this code is split, having the actual catch clause somewhere at the end of the function:

 try
               {
                  throw 4711;             /* GDB Test (cplusplus.cpp,1) */
  17b3ae:       f04f 0004       mov.w   r0, #4
  17b3b2:       f09c fba9       bl      217b08 <__cxa_allocate_exception>
  17b3b6:       4603            mov     r3, r0
  17b3b8:       f241 2267       movw    r2, #4711       ; 0x1267
  17b3bc:       601a            str     r2, [r3, #0]
  17b3be:       4618            mov     r0, r3
  17b3c0:       f64c 0118       movw    r1, #51224      ; 0xc818
  17b3c4:       f04f 0302       mov.w   r3, #2
  17b3c8:       623b            str     r3, [r7, #32]
  17b3ca:       f2c0 012c       movt    r1, #44 ; 0x2c
  17b3ce:       f04f 0200       mov.w   r2, #0
  17b3d2:       f09d fc45       bl      218c60 <__cxa_throw>

....

 try
               {
                  throw 4711;             /* GDB Test (cplusplus.cpp,1) */
               }
               catch (int i)              /* GDB Test (cplusplus.cpp,2) */
  17b530:       4618            mov     r0, r3
  17b532:       f09c fd59       bl      217fe8 <__cxa_begin_catch>
  17b536:       4603            mov     r3, r0
  17b538:       681b            ldr     r3, [r3, #0]
  17b53a:       677b            str     r3, [r7, #116]  ; 0x74
               {
                  blue::fibonacci(5);     /* GDB Test (cplusplus.cpp,3) */
  17b53c:       f04f 0005       mov.w   r0, #5
  17b540:       f7ff fcc2       bl      17aec8 <_ZN4blue9fibonacciEi>

On Powerpc GDB installs a second breakpoint on the "_Unwind_DebugHook" function. Then, after stepping over this hook GDB will install another 3 breakpoints: one after the call to _cxa_throw in the first block, one on the catch block in the second (which is of interest) and another breakpoint on DebugHook. Thus at some point the breakpoint on fibonacci will be reached. On ARM there is no DebugHook so the target will not know when to stop. The "next" command will only issue a step through range 17b3ae-17b3d2. How can the GDB stub on the target side reach the branch to the fibonacci function at 17b540? Perhaps we need to install additional breakpoints like on PPC?
Comment 1 Sergio Durigan Junior 2013-10-29 23:36:57 UTC
Thanks for the report.  Would it be possible for you to test with a more recent GDB and GCC?  I think I implemented the support for this on ARM last year, but you will need a recent GDB with support to SystemTap SDT probes (and a recent GCC/libgcc too).
Comment 2 Toma Bilius 2013-11-01 13:03:07 UTC
(In reply to Sergio Durigan Junior from comment #1)
> Thanks for the report.  Would it be possible for you to test with a more
> recent GDB and GCC?  I think I implemented the support for this on ARM last
> year, but you will need a recent GDB with support to SystemTap SDT probes
> (and a recent GCC/libgcc too).

I tested with GDB 7.6.1 and the behavior is the same (compiler version is 4.6.3). Unfortunately updating the compiler is a more complex task for our project. Does the new version of GCC insert a default probe that GDB will look after when installing the breakpoints?

Thank you.
Comment 3 Sergio Durigan Junior 2013-11-04 04:57:01 UTC
(In reply to Toma Bilius from comment #2)

> I tested with GDB 7.6.1 and the behavior is the same (compiler version is
> 4.6.3). Unfortunately updating the compiler is a more complex task for our
> project. Does the new version of GCC insert a default probe that GDB will
> look after when installing the breakpoints?

Yeah, just updating GDB won't solve the problem.  It needs support from the GCC side (libgcc specifically), and you won't have it until you update GCC.

Newer versions of GCC provide a probe located at libgcc which makes it possible for GDB to do what you want.  I implemented it with the following patch:

<http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02246.html>

As you can see there, before the patch libgcc for ARM did not provide even _Unwind_DebugHook, so it is not possible to use it even without probes...  I can't think of anything you could do except updating the GCC version you are using (maybe someone else can, let's wait to see if others can say something about this).

If nobody answers in a few days, I will close this as INVALID because it is not GDB's fault, and because your GCC version does not provide the necessary infrastructure unfortunately.  But please, don't hesitate to reopen this bug if you have some new information about this.

Thanks.
Comment 4 Sergio Durigan Junior 2013-11-04 04:58:35 UTC
Ops, I meant to say that I was going to close this bug now.  Reopen if needed, please.
Comment 5 Toma Bilius 2013-11-04 09:17:40 UTC
(In reply to Sergio Durigan Junior from comment #4)
> Ops, I meant to say that I was going to close this bug now.  Reopen if
> needed, please.

Ok, thank you for your input.