1

I have been working with some Cortex-M4 (Freescale K60) devices with a compiled by me GCC (v4.7.2), BinUtils (v2.22), Newlib (v1.20) and GDB (v7.5). I have always been annoyed by GDB's inability to unwind from hard exceptions.

recently I had an opportunity to use FreeScale's CodeWarrior, where I loaded my binary for debug (compiled by my tools), and it could unwind the exception. It looks like CodeWarrior is running GDB v7.4.1 under the hood. Is there some patch I missed for GDB, or some configure option?

Here is the script used to build GDB: TOOLCHAIN=gdb-7.5 mkdir -p BUILD/gdb cd BUILD/gdb ../../${TOOLCHAIN}/configure --prefix=${PREFIX} --target=${TARGET} --enable-interwork --enable-multilib --with-expat=yes --with-python --without-auto-load-safe-path 2>&1 | tee configure.out make all install cd ../../

Thanks!

norton256
  • 33
  • 6

1 Answers1

1

GDB can do Cortex M profile exception unwinding, once you tell it that the target is actually Cortex M profile using a Target Description XML with correct Feature.

This can be done via the set target tdesc <filename> command, but newer gdb servers (e.g. OpenOCD) should do so already.

Turbo J
  • 7,563
  • 1
  • 23
  • 43
  • That looks to be what I am missing, but when I try to set architecture manually in gdb it does not understand armv7m
    from gdb:
    (gdb) set architecture armv7m
    Undefined item: "armv7m".
    (gdb) set architecture
    Requires an argument. Valid arguments are arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, auto.
     – norton256 Feb 24 '15 at 14:25
  • Sorry for the horrible formatting... That looks to be what I am missing, but when I try to set architecture manually in gdb it does not understand armv7m. Maybe I did miss something when I built GDB? gdb output: `(gdb) set architecture armv7m Undefined item: "armv7m". (gdb) set architecture Requires an argument. Valid arguments are arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, auto.` – norton256 Feb 24 '15 at 14:36
  • after doing some more reading, it looks like i should be using the "arm" architecture with the "org.gnu.gdb.arm.m-profile" feature. Since it seems that the feature configures the registers, which are configured when I'm debugging, then it appears OpenOCD is configuring GDB properly. Maybe something is getting confused with stack switching? – norton256 Feb 24 '15 at 14:51
  • Only newest OpenOCD does this correctly IIRC. Which version do you use? – Turbo J Feb 24 '15 at 15:39
  • I'm running OpenOCD 0.7.0 – norton256 Feb 25 '15 at 17:57
  • Waaaay too old. I'm not sure that even 0.8.0 is new enough, try one of the newer snapshots of 0.9.0. – Turbo J Feb 25 '15 at 19:44
  • Just checked the release notes, 0.8.0 should work, too. – Turbo J Feb 25 '15 at 19:46
  • After a years worth of time I have finally had the opportunity to upgrade to OpenOCD 0.9.0, and it is still unable to backtrace through an exception. I have manually set the target description to the arm-m-profile.xml which ships with gdb and still no luck. – norton256 Mar 17 '16 at 15:25