Illegal (iLLegal) instruction 直观解释----非法指令。表面看是CPU在执行指令过程中，发现指令非法，也就是不认识的指令或者无权限的指令。如果只是沿着这个思路，很容易陷入对编译器的信任上。其实，这个问题，也很可能是程序自己造成的。比如使用了嵌入汇编，那么编写者要对使用的指令负责。还比如堆栈、内存出错，此时，访问的指令可能是内存随机的数据或者非指令数据，这同样会导致CPU无法识别。网上看到一篇比较全的分析文章，放在这里供参考：

非法指令(Illegal Instruction)问题定位 - ArnoldLu - 博客园

关于这个问题需要再补充一下：

之前没有经过认真思考，就做出了上述论断，后来仔细想了想，感觉没有那么简单。对于第一种情况，使用嵌入汇编，实际测试，发现如果使用了错误的汇编指令，编译器是不认的。想想也是，嵌入汇编也是一种格式，也有很多种扩展写法，编译器并不是按照类似宏定义的方式，直接信任和使用的，而是需要进行二次处理，保留基本处理流程，重新生成不影响上下文的汇编指令（寄存器使用通盘考虑）。这样一来，想通过嵌入汇编轻松欺骗机器是行不通的。关于嵌入汇编，简单的例子可参考下面的链接：

内联汇编很可怕吗？看完这篇文章，终结它！

继续，对于第二种情况，修改代码指令，也不是简单轻松的事情。现代操作系统都是用了虚拟内存机制，进一步的，大部分都采用了分页机制。那么，对于程序的代码段，操作系统在映射内存页面的时候，会标记这类页面为只读，所以，尝试对代码直接修改，也是行不通的。

对于这一点，也不是绝对的。可以通过mprotect调用，修改页面的读写属性，参考文章：

内核热补丁，真的安全么？

综合上述两点，人为产生非法指令，还需要再思考思考。

第三次补充：在X86下尝试多次均失败后，终于在arm下人为成功产生了上述错误指令提示。具体过程如下：

首先，对程序做了简单处理，增加了如下的异常信号捕获

void signal_handler(int signum) {
   printf("Signal %d (number) captured \n", signum);
}

signal(SIGILL , signal_handler);

上述代码期望在非法指令产生时，由应用捕获，并进一步处理。

然后对于x86，因为简单的错误指令会被编译器识别，所以主要尝试了call和jmp指令。在这两个指令后都附带一个随机地址，可以编译通过。但是，实际运行，都是类似段错误，也就是主要是内存错误。
call因为是类似函数调用，有入栈出栈等操作，段错误还是可以理解的，但是jmp指令是无条件跳转，跳转到的地址包含的内容可能不是有效的代码，比如无法译码。但是，多次尝试，仍然也是报段错误。x86下放弃。

尝试ARM平台。找到了一个跟CPU版本相关的指令，swpb，这是一个存在于早期ARM CPU上的指令，感兴趣的读者可以搜索了解一下。
使用如下嵌入汇编代码

asm volatile("swpb %0,%2,[%3]"
             : "=&r"(ret), "=m" (*ptr)
             : "r"(newval), "r"(ptr)
             : "cc", "memory");    //memory == no cache  |  cc == status register update

编译通过。执行程序，报非法指令。
gdb跟踪调试，发现报非法指令时，的确在swpb指令处。如下图：

Program received signal SIGILL, Illegal instruction.    成功产生非法指令。
这说明，在嵌入式平台上，可能会因为嵌入汇编、编译器版本、连接库等导致出现运行时非法指令。