通过newlib传递的GDB调试参数

时间:2015-05-29 23:28:15

标签: c gcc gdb arm newlib

我正在尝试在TI CC2538 ARM Cortex M3部件上使用newlib。目标是使用printf来调试消息,我实际上已经开始工作了。但是,系统会在一些消息(ARM调用HardFault)之后发生段错误,而我不明白为什么。

我使用GDB获取以下堆栈跟踪:

(gdb) bt full
#0  FaultISR () at src/startup_gcc.c:307
        fault_stat = 0x8200
        hfault_stat = 0x40000000
        mmfault_stat = 0xfffffff8
        busfault_stat = 0xfffffff8
        buf = "\000\000\000\000\371\377\377\377\026\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\b\f\000 \002\000\000\000\060\r\000 \320\f\000 \002\000\000\000\303w \000\000\000\000\000w?\032\000\360\v\000 \360\v\000 \002\000\000\000\027\000\000\000\003\000\000\000\277\022\035\000\b\f\000 \b\f\000  \r\000 \027\000\000\000\f\000\000\000\371\377\377\377T\025\000 a\217 \000\r\000\000\000\001\000\000\000\210\r\000 s\263\""
#1  <signal handler called>
No symbol table info available.
#2  0x002076dc in strlen ()
No symbol table info available.
#3  0x0020494a in _svfprintf_r ()
No symbol table info available.
#4  0x002045aa in _vsnprintf_r ()
No symbol table info available.
#5  0x002045fe in vsnprintf ()
No symbol table info available.
#6  0x00200fa8 in ws_debug_vfprintf (f=STDERR, fmt=0x208f24 "Received a packet of length %u\n", args=...) at src/os/ws_debug.c:220
        len = 0x27
        buf = 0x20001538 "DBG src/net/mac/packet_scheduler.c:123 "
#7  0x00200f4e in ws_debug_fprintf (f=STDERR, fmt=0x208f24 "Received a packet of length %u\n") at src/os/ws_debug.c:201
        args = {__ap = 0x20000e50 <pui32Stack+440>}
#8  0x00201dea in packet_scheduler_timer () at src/net/mac/packet_scheduler.c:123
        phy_len = 0xd
        pkt = 0x8ef6
        fcf = 0x0
        buf = 0x20001738 "\200\220"
#9  0x00200c32 in ws_timer_update () at src/os/ws_timer.c:156
        ptr = 0x20001728
        new = 0x20001728
#10 0x002005c2 in main () at src/main.c:143
No locals.

正如您所看到的,newlib部件(#2 - #5)没有任何信息,因此很难调试。我假设这是因为newlib被删除了调试符号,但是我重新编译了newlib并得到了相同的结果。

我使用官方回购中提供的工具链运行Arch linux。

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/5.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-5-20150519/configure --target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi --with-native-system-header-dir=/include --libexecdir=/usr/lib --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib --with-headers=/usr/arm-none-eabi/include --with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf --enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/ --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 5.1.0 (Arch Repository)

-

arm-none-eabi-gdb -v
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

我使用Arch Build System(ABS)手动构建了newlib包,我认为应该包含调试符号(函数名称显示在GDB中。这还够吗?)

关于我接下来可以尝试的任何想法?

修改

我修改了输出,因此故障状态寄存器实际上是可读的。

这是解码输出:

fault_stat: 0x8200 (BFARV, PRECISE)
hfault_stat: 0x40000000 (FORCED)
busfault_stat: 0xfffffff8 (valid FAULTADDR)

解释说,我们有一个总线故障异常,其中包含存储在FAULTADDR中的违规指令的地址。我不确定是什么导致CPU尝试拨打0xffffff8,但我很确定这会导致问题。

0 个答案:

没有答案