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?
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).
(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.
(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.
Ops, I meant to say that I was going to close this bug now. Reopen if needed, please.
(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.