本文介绍了调试器外编程OK，步进时调试器下SIGILL?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
我正在尝试在 BeagleBone Black 上调试程序.在调试器之外，它会产生不正确的结果，但不会产生 SIGILL.它也可以在没有断点的调试器下正常运行.但是，它会在单步执行时生成带有断点设置的 SIGILL.该程序和库不使用基于 SIGILL 的 cpu 功能探测器.但是，我不知道 GDB 在做什么.
在我看到的调试器下:
(gdb) b main0x26f20 处的断点 1:文件 test.cxx，第 22 行.(gdb) r启动程序:/home/cryptopp/test.exe断点 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:2222 字节密钥 [16] = {0};(gdb) n23 字节 iv[12] = {0}；(gdb)25 GCM<AES>::加密加密；(gdb)26 enc.SetKeyWithIV(key, 16, iv, 12);(gdb)28 std::string 普通(0x00，16)；(gdb)程序收到信号SIGILL，非法指令.std::basic_ostream 中的 0x00026d5c>&std::endl>(std::basic_ostream<char, std::char_traits<char> >&)()(gdb) n单步执行直到退出函数 _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_，它没有行号信息.程序以信号 SIGILL 终止，非法指令.该程序不再存在.还有:
(gdb) shell echo _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ |C++过滤器std::basic_ostream>&std::endl>(std::basic_ostream<char, std::char_traits<char> >&)我尝试搜索此问题，但找不到匹配项.我的噪音太大了.
当 GDB 设置断点时，为什么我会遇到 SIGILL，我该如何解决?
NEON 是我要调查的问题.这是用于程序和库的命令行:
$ echo $CXXFLAGS-DDEBUG -g3 -O0 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard$ g++ $CXXFLAGS test.cxx ./libcryptopp.a -o test.exe还有:
$ gdb --versionGNU gdb (Debian 7.7.1+dfsg-5) 7.7.1$ uname -aLinux beaglebone 4.1.15-ti-rt-r40 #1 SMP PREEMPT RT Thu Jan 7 23:32:08 UTC 2016 armv7l GNU/Linux$ cat/proc/cpuinfo处理器:0型号名称:ARMv7 处理器修订版 2 (v7l)BogoMIPS : 996.14特点:半拇指 fastmult vfp edsp 拇指霓虹灯 vfpv3 tls vfpd32CPU 实现者:0x41CPU架构:7CPU变体:0x3CPU部分:0xc08CPU版本:2硬件:通用 AM33XX(扁平设备树)修订:0000序列号:0000000000000000还有:
断点 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:2222 字节密钥 [16] = {0};(gdb) n23 字节 iv[12] = {0}；(gdb)25 GCM<AES>::加密加密；(gdb)26 enc.SetKeyWithIV(key, 16, iv, 12);(gdb)28 std::string 普通(0x00，16)；(gdb)程序收到信号SIGILL，非法指令.std::basic_ostream 中的 0x00026d5c>&std::endl>(std::basic_ostream<char, std::char_traits<char> >&)()(gdb) 向上#1 0x00026f82 in main (argc=0x1, argv=0xbeffea54) at test.cxx:2828 std::string 普通(0x00，16)；(gdb) 解除函数 main(int, char**) 的汇编代码转储:0x00026f10 <+0>:推{r4, r7, lr}0x00026f12 <+2>: sub.w sp, sp, #916;0x3940x00026f16 <+6>:添加 r7、sp、#160x00026f18 <+8>:添加 r3、r7、#40x00026f1a <+10>: str r0, [r3, #0]0x00026f1c <+12>: mov r3, r70x00026f1e <+14>: str r1, [r3, #0]0x00026f20 <+16>: add.w r3, r7, #692;0x2b40x00026f24 <+20>:movs r2，#00x00026f26 <+22>: str r2, [r3, #0]0x00026f28 <+24>:添加 r3，#40x00026f2a <+26>:movs r2，#00x00026f2c <+28>: str r2, [r3, #0]0x00026f2e <+30>:添加 r3，#40x00026f30 <+32>:movs r2，#00x00026f32 <+34>: str r2, [r3, #0]0x00026f34 <+36>:添加 r3，#40x00026f36 <+38>:movs r2，#00x00026f38 <+40>: str r2, [r3, #0]0x00026f3a <+42>:添加 r3，#40x00026f3c <+44>: add.w r3, r7, #680;0x2a80x00026f40 <+48>:movs r2，#0---类型<返回>继续，或 q <return>退出 - -0x00026f42 <+50>: str r2, [r3, #0]0x00026f44 <+52>:添加 r3，#40x00026f46 <+54>:movs r2，#00x00026f48 <+56>: str r2, [r3, #0]0x00026f4a <+58>:添加 r3，#40x00026f4c <+60>:movs r2，#00x00026f4e <+62>: str r2, [r3, #0]0x00026f50 <+64>:添加 r3，#40x00026f52 <+66>: add.w r3, r7, #240;0xf00x00026f56 <+70>: 移动 r0, r30x00026f58 <+72>: bl 0x2a804 <CryptoPP::GCM_Final<CryptoPP::Rijndael, (CryptoPP::GCM_TablesOption)0, true>::GCM_Final()>0x00026f5c <+76>: add.w r1, r7, #240;0xf00x00026f60 <+80>: add.w r2, r7, #692;0x2b40x00026f64 <+84>: add.w r4, r7, #680;0x2a80x00026f68 <+88>:movs r3，#120x00026f6a <+90>: str r3, [sp, #0]0x00026f6c <+92>: mov r0, r10x00026f6e <+94>: mov r1, r20x00026f70 <+96>:movs r2，#160x00026f72 <+98>: mov r3, r40x00026f74 <+100>: bl 0x2da0c <CryptoPP::SimpleKeyingInterface::SetKeyWithIV(unsigned char const*, unsigned int, unsigned char const*, unsigned int)>---类型<返回>继续，或 q <return>退出 - -0x00026f78 <+104>: add.w r3, r7, #708;0x2c40x00026f7c <+108>: mov r0, r30x00026f7e <+110>: blx 0x26d58 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_+852>=>0x00026f82 <+114>: add.w r2, r7, #676;0x2a40x00026f86 <+118>: add.w r3, r7, #708;0x2c40x00026f8a <+122>: mov r0, r20x00026f8c <+124>:movs r1，#00x00026f8e <+126>:movs r2，#16... 解决方案
感谢 @ks1322，这是一个已知的 GDB/内核错误.参见 GDB 在 ARM SMP 双核系统上调试多线程程序时崩溃GDB 问题跟踪器.
根据 Debian BTS，这也是一个已知问题.请参阅 在 Debian BTS 中单步执行 armhf 上的应用程序时的 SIGILL.
这个错误被重新填充，希望它可能在未来一两年的某个时候得到修复.请参阅 GDB/Kernel 生成 SIGILL 导致 GDB 崩溃>
这就是我鄙视 Debian 的错误报告系统的原因.东西被报告，然后它就腐烂了.没有什么是固定的.
I'm trying to debug a program on a BeagleBone Black. Outside the debugger it produces an incorrect result but no SIGILL. It also runs OK under the debugger without a breakpoint. However it produces a SIGILL with a breakpoint set when stepping. The program and library does not use SIGILL-based cpu feature probes. However, I don't know what GDB is doing.
Under the debugger I am seeing:
(gdb) b main
Breakpoint 1 at 0x26f20: file test.cxx, line 22.
(gdb) r
Starting program: /home/cryptopp/test.exe
Breakpoint 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:22
22 byte key[16] = {0};
(gdb) n
23 byte iv[12] = {0};
(gdb)
25 GCM<AES>::Encryption enc;
(gdb)
26 enc.SetKeyWithIV(key, 16, iv, 12);
(gdb)
28 std::string plain(0x00, 16);
(gdb)
Program received signal SIGILL, Illegal instruction.
0x00026d5c in std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
()
(gdb) n
Single stepping until exit from function _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_,
which has no line number information.
Program terminated with signal SIGILL, Illegal instruction.
The program no longer exists.
And:
(gdb) shell echo _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ | c++filt
std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
I tried searching for this issue, but I have not been able to locate a hit. I'm getting too much noise.
Why am I experiencing a SIGILL when GDB sets a breakpoint, and how do I work around it?
NEON is the problem I am trying to investigate. Here's the command line used for the program and library:
$ echo $CXXFLAGS
-DDEBUG -g3 -O0 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard
$ g++ $CXXFLAGS test.cxx ./libcryptopp.a -o test.exe
And:
$ gdb --version
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
$ uname -a
Linux beaglebone 4.1.15-ti-rt-r40 #1 SMP PREEMPT RT Thu Jan 7 23:32:08 UTC 2016 armv7l GNU/Linux
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 996.14
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
And:
Breakpoint 1, main (argc=0x1, argv=0xbeffea54) at test.cxx:22
22 byte key[16] = {0};
(gdb) n
23 byte iv[12] = {0};
(gdb)
25 GCM<AES>::Encryption enc;
(gdb)
26 enc.SetKeyWithIV(key, 16, iv, 12);
(gdb)
28 std::string plain(0x00, 16);
(gdb)
Program received signal SIGILL, Illegal instruction.
0x00026d5c in std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
()
(gdb) up
#1 0x00026f82 in main (argc=0x1, argv=0xbeffea54) at test.cxx:28
28 std::string plain(0x00, 16);
(gdb) disass
Dump of assembler code for function main(int, char**):
0x00026f10 <+0>: push {r4, r7, lr}
0x00026f12 <+2>: sub.w sp, sp, #916 ; 0x394
0x00026f16 <+6>: add r7, sp, #16
0x00026f18 <+8>: adds r3, r7, #4
0x00026f1a <+10>: str r0, [r3, #0]
0x00026f1c <+12>: mov r3, r7
0x00026f1e <+14>: str r1, [r3, #0]
0x00026f20 <+16>: add.w r3, r7, #692 ; 0x2b4
0x00026f24 <+20>: movs r2, #0
0x00026f26 <+22>: str r2, [r3, #0]
0x00026f28 <+24>: adds r3, #4
0x00026f2a <+26>: movs r2, #0
0x00026f2c <+28>: str r2, [r3, #0]
0x00026f2e <+30>: adds r3, #4
0x00026f30 <+32>: movs r2, #0
0x00026f32 <+34>: str r2, [r3, #0]
0x00026f34 <+36>: adds r3, #4
0x00026f36 <+38>: movs r2, #0
0x00026f38 <+40>: str r2, [r3, #0]
0x00026f3a <+42>: adds r3, #4
0x00026f3c <+44>: add.w r3, r7, #680 ; 0x2a8
0x00026f40 <+48>: movs r2, #0
---Type <return> to continue, or q <return> to quit---
0x00026f42 <+50>: str r2, [r3, #0]
0x00026f44 <+52>: adds r3, #4
0x00026f46 <+54>: movs r2, #0
0x00026f48 <+56>: str r2, [r3, #0]
0x00026f4a <+58>: adds r3, #4
0x00026f4c <+60>: movs r2, #0
0x00026f4e <+62>: str r2, [r3, #0]
0x00026f50 <+64>: adds r3, #4
0x00026f52 <+66>: add.w r3, r7, #240 ; 0xf0
0x00026f56 <+70>: mov r0, r3
0x00026f58 <+72>: bl 0x2a804 <CryptoPP::GCM_Final<CryptoPP::Rijndael, (CryptoPP::GCM_TablesOption)0, true>::GCM_Final()>
0x00026f5c <+76>: add.w r1, r7, #240 ; 0xf0
0x00026f60 <+80>: add.w r2, r7, #692 ; 0x2b4
0x00026f64 <+84>: add.w r4, r7, #680 ; 0x2a8
0x00026f68 <+88>: movs r3, #12
0x00026f6a <+90>: str r3, [sp, #0]
0x00026f6c <+92>: mov r0, r1
0x00026f6e <+94>: mov r1, r2
0x00026f70 <+96>: movs r2, #16
0x00026f72 <+98>: mov r3, r4
0x00026f74 <+100>: bl 0x2da0c <CryptoPP::SimpleKeyingInterface::SetKeyWithIV(unsigned char const*, unsigned int, unsigned char const*, unsigned int)>
---Type <return> to continue, or q <return> to quit---
0x00026f78 <+104>: add.w r3, r7, #708 ; 0x2c4
0x00026f7c <+108>: mov r0, r3
0x00026f7e <+110>: blx 0x26d58 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_+852>
=> 0x00026f82 <+114>: add.w r2, r7, #676 ; 0x2a4
0x00026f86 <+118>: add.w r3, r7, #708 ; 0x2c4
0x00026f8a <+122>: mov r0, r2
0x00026f8c <+124>: movs r1, #0
0x00026f8e <+126>: movs r2, #16
...
解决方案
Thanks to @ks1322, this is a known GDB/Kernel bug. See GDB crashes on debugging multithreaded program on ARM SMP dual core system in the GDB issue tracker.
According to the Debian BTS, this is also a known issue. See SIGILL when stepping through application on armhf in the Debian BTS.
The bug was refilled in hopes that it might actually be fixed sometime in the next year or two. See GDB Crash due to GDB/Kernel generated SIGILL
This is why I despise Debian's bug reporting systems. Stuff gets reported and then it just rots. Nothing gets fixed.
这篇关于调试器外编程OK，步进时调试器下SIGILL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！