arm-eabi-gdb 与 redboot 配合调试 ecos application

redboot跑起来了，下了个hello world的ecos程序也跑起来了，我写了一个简单的ecos程序，用redboot和arm-eabi-gdb来调试它，按照下面的步骤，开始都ok.

 

arm-eabi-gdb test.elf -b 19200 -nw

target remote /dev/ttyS0

load

break 20

c

 

程序顺利运行到所设的断点处

 

然后gdb命令查看内存，寄存器，变量的值，反汇编等，都正常，但只要再往下运行一行语句，程序就跑飞了。

 

为了查找问题，首先要搞清楚redboot是怎样单步运行程序的。下面是redboot与gdb通讯过程概述。

 

redboot起动，进入readboot主循环。此main_loop定义在.../packages/redboot/.../src/main.c中。

 

当收到一个$符时，redboot即进入到调试状态，由debug_stub接管控制权，执行顺序为：

 

                gdb_stack_sp = (CYG_ADDRESS)workspace_end;
                // set up a temporary context that will take us to the trampoline
                HAL_THREAD_INIT_CONTEXT(gdb_stack_sp,
                                        breakpoint, trampoline,0);

                // switch context to trampoline (get GDB stubs started)
                HAL_THREAD_SWITCH_CONTEXT(&saved_context, &gdb_stack_sp);

 

HAL_THREAD_INIT_CONTEXT建立一个临时context, 程序运行进入trampoline函数，在trampoline执行breakpoint,

 

breakpoint定义在hal/arm/arch/src/hal_misc.c中, 其中安放着一条非法指令，当程序运行至breakpoint时，便发生异常，控制权交到

 

generic-stub.c中定义的__handle_exception, 这里也有一个主循环，接收来自gdb的数据，并处理它，大部分命令由函数__process_packet处理，当收到Continue, step, 等命令时，会在相应位置设置好断点，断点仍然而是一条非法指令，并不是swi, 然后程序会退出主循环，控制权交回到定义在vector.S中的异常处理程序，

 

#ifndef CYGOPT_HAL_ARM_PRESERVE_SVC_SPSR
        msr     spsr,r0
        ldmeqfd sp,{r0-r14,pc}^
endif

 

这两句话可让程序进入到我们要调试的程序，因为堆栈上保存的是我们的正在调试的程序的context, 这两句话实际上是恢复了我们正在调试的程序的context. 之后当程序遇到我们所设的断点时，会再次进入到异常处理程序，从而再次把控制权交给generic-stub.c中定义的__handle_exception.

 

我的问题发生在

        ldmeqfd sp,{r0-r14,pc}^

这句话上，当程序运行到此处时就飞了。

我改成

        ldmeqfd sp,{r0-r14,pc}就可以，这说明状态寄存器有问题，打印出来看了一下，spsr的值是0x60000013, 而原先的cpsr是0x600000d3, 区别就只是有没有禁止irq和fiq, 应该是我的中断服务程序有问题。明天接着看。