标签：style blog color 使用 strong 文件
在移植uboot时编译一切正常，但uboot启动中加载自己写的网卡驱动出现问题，一直在打印raise：Signal #8 caught
google 百度了一番，也有很多人遇到了这个问题，大家都说出了解决问题的办法，
就是自己编写的驱动中有出现除以0的误操作，就会一直打印raise：Signal #8 caught
将除操作改为位移操作，或者避免除数为0，就可以解决这个问题。
那为什么有除以0的操作就会引发raise： Signal #8 caught ? 来分析一番！
遇到错误打印，首先要找到打印来源于哪个函数，在uboot源码中grep一把，找到该打印的来源，在arch/arm/lib/eabi_compat.c中，如下：
int raise (int signum)
{
/* Even if printf() is available, it's large. Punt it for SPL builds */
#if !defined(CONFIG_SPL_BUILD)
printf("raise: Signal # %d caught\n", signum);
#endif
return 0;
}
eabi_compat.c是为符合eabi接口的工具链提供一些通用的函数。
看到raise函数的实现，感觉参数signum好像是代表信号的意思（C语言中变量名是多么重要啊！），想起在网络编程中有一个函数raise是用来自身进程发信号。
那么这里一直打印signal #8 caught，是不是一直在发8号信号，搜了一下linux下的64种信号，8号代表的是SIGFPE，当一个进程遇到一个错误的算术操作时就会发送该信号。
这不就跟大家给出的解决办法是一致的嘛，因为出现了除以0的操作，所以会发SIGFPE信号！
但是这样的解释还是有很大漏洞，raise发出信号，谁调它发的SIGFPE，grep源码，根本找不到调用raise的地方！
linux系统下用户空间出现除以0的非法操作，进程就发SIGFPE信号，信号是什么，其实就是软中断，使用指令SWI使处理器陷入内核态，内核态中的异常处理捕获处理该错误。
写一个简单的测试程序，如下：
#include <stdio.h>
void main()
{
int a = 100;
int c= 0;
c = a / 0;
}
静态交叉编译（将所有需要函数都拷贝进来），然后objdump反汇编，查看反汇编文件，找到main函数：
00008428 <main>:
8428: e92d4800 push {fp, lr}
842c: e28db004 add fp, sp, #4 ; 0x4
8430: e24dd008 sub sp, sp, #8 ; 0x8
8434: e3a03064 mov r3, #100 ; 0x64
8438: e50b300c str r3, [fp, #-12]
843c: e3a03000 mov r3, #0 ; 0x0
8440: e50b3008 str r3, [fp, #-8]
8444: e51b300c ldr r3, [fp, #-12]
8448: e3a02000 mov r2, #0 ; 0x0
844c: e1a00003 mov r0, r3
8450: e1a01002 mov r1, r2
8454: eb000003 bl 8468 <__aeabi_idiv>
8458: e1a03000 mov r3, r0
845c: e50b3008 str r3, [fp, #-8]
8460: e24bd004 sub sp, fp, #4 ; 0x4
8464: e8bd8800 pop {fp, pc}
大体阅读下，
除操作‘/’编译之后成了调用__aeabi_idiv，网上搜索一番，原来对于满足eabi（嵌入式arm应用程序二进制接口）的arm工具链，编译时编译器将编译对象的‘/‘操作替换为调用__aeabi_idiv函数，__aeabi_idiv是由libgcc.so或gcc.a库提供的。
反汇编文件中也有__aeabi_idiv的反汇编实现，大体看下，如下：
<span style="font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);"></span><pre name="code" class="cpp">00008468 <__aeabi_idiv>:
8468: e3510000 cmp r1, #0 ; 0x0
846c: 0a000081 beq 8678 <.divsi3_nodiv0+0x208>
00008470 <.divsi3_nodiv0>:
8470: e020c001 eor ip, r0, r1
8474: 42611000 rsbmi r1, r1, #0 ; 0x0
8478: e2512001 subs r2, r1, #1 ; 0x1
8460: e3500000 cmp r0, #0 ; 0x0
8464: c3e00102 mvngt r0, #-2147483648 ; 0x80000000
8468: b3a00102 movlt r0, #-2147483648 ; 0x80000000
846c: ea000007 b 8490 <__aeabi_idiv0>
00008470 <__aeabi_idivmod>:
8470: e3510000 cmp r1, #0 ; 0x0
8474: 0afffff9 beq 8460 <.divsi3_nodiv0+0x208>
8478: e92d4003 push {r0, r1, lr}
847c: ebffff75 bl 8258 <.divsi3_nodiv0>
8480: e8bd4006 pop {r1, r2, lr}
8484: e0030092 mul r3, r2, r0
8488: e0411003 sub r1, r1, r3
848c: e12fff1e bx lr
00008490 <__aeabi_idiv0>:
8490: e92d4002 push {r1, lr}
8494: e3a00008 mov r0, #8 ; 0x8
8498: eb0007d8 bl a400 <raise>
849c: e8bd8002 pop {r1, pc}
调用__aeabi_idiv0，而__aeabi_idv0则调用raise，参数为8
Crazy！原来是这里调用的raise函数！
这也就解释了为什么在源码中找不到调用raise的代码，因为调用raise不是代码本身，而是eabi的arm工具链给出的数学运算函数。
arm工具链的__aeabi_div除数为0则会调用raise，发SIGFPE信号。这样整个的解释就通了！
uboot是裸机程序，是非GNU/linux的程序。
linux内核也是满足eabi的GNU/linux程序，符合eabi的arm工具链是GNU/linux工具链，eabi接口规定了内核的系统调用 信号规范，arm工具链编译linux内核，内核实现中会去实现raise函数。
也就是说arm工具链的__aeabi_idiv与linux内核的raise出现了交叉调用，有了依赖关系！
这样裸机程序如uboot可就受苦了，不过uboot中实现了如上的raise空函数，来让arm工具链的__aeabi_div来调用，只是打印一下，而不做处理，
就是我们看到的raise：Signal #8 caught！
这也算是提个醒，以后做裸机程序，用eabi的arm工具链，如果代码中有除操作，记得链接libgcc.so和实现raise函数。
uboot中raise：Signal #8 caught的根本原因,布布扣,bubuko.com
uboot中raise：Signal #8 caught的根本原因
标签：style blog color 使用 strong 文件
原文地址：http://blog.csdn.net/skyflying2012/article/details/36418131
