GDB is crashing on GNU Tools ARM Embedded 4.7

Hello Kevin,

Can you please be more specific on your issue like what board and gdb server you are using? If possible, can you provide a small example for others to reproduce your issue? Those will be great helpful for us to look into the issue.

I have the same problem with last release (4.7 2013q2):

arm-none-eabi-gdb.exe has stopped working.

I use SEGGER J-Link GDB Server V4.72a and STM3240G Evaluation board.

P.S. I have the same problem with ALL 4.7 releases.

P.S. If I use arm-none-eabi-gdb.exe of Yagarto or Sourcery its works fine.

Hi Denys,

what do you mean for "arm-none-eabi-gdb.exe has stopped working"? Is arm-none-eabi-gdb simply crashed or something else? I tried with same GDB server and TWR-K60N512 board on win 7 64bit machine. The gdb can connect to board and show the register info.

Hi Denys,

what do you mean for "arm-none-eabi-gdb.exe has stopped working"? Is arm-none-eabi-gdb simply crashed or something else? I tried with same GDB server and TWR-K60N512 board on win 7 64bit machine. The gdb can connect to board and show the register info.

Additional info for arm-none-eabi-gdb crashing:

arm-none-eabi-gdb crash ONLY when I choose a Maximum(-g3) debug level in Project properties.
In ALL other conditions it works fine.

Still no luck to reproduce the issue. The gdb works well for binaries with -g3 debug level. I am using gdb standalone on win7 64, not using gdb through IDE.

It sounds like you are calling gdb through IDE. If so, what IDE are you using?

Same problem.
Initially I discovered issue with Yagrato toolchain (build 20121222). After I made some source code modifications to our project (complex and working) I faced with surprising gdb failure: right after gdb connected to target it hangs and starts consume memory until it chocks at windows process memory limit and produces error as described in old gdb bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9232 (in my case it was 4072 bytes only, although it eaten around 2GB actually).
Same project built and run with GNU Tools ARM Embedded 4.7 2013q1 results in gdb crash at same place.
I haven't found a way to produce simple test case. For example it doesn't crash just after I remove some function call somewhere. Funny, but large and long developed project works ok as opposed to it's heavily reduced and shrinked version.
I confirm that changing maximum debug level (-g3) to default (-g) resolves issue (in both toolchains).
OS: Windows 7 Pro x64.

Sorry that I forgot to update this thread. I think the issue here is same as the one at https://answers.launchpad.net/gcc-arm-embedded/+question/234131. And the reason for such issue is incomplete support to GNU DWARF extension in gdb, especially the DWARF extensions for C Macro. The recent gdb like 7.6 should provide better support and fix this issue.

If build app with gcc -g3 option, a DWARF entry named DW_MACRO_GNU_transparent_include will be generated to record Macro information. When parsing this entry in gdb, gdb will fall into an endless recursive call. That's why we can see the constantly memory consume.