程序在调试器外部调试程序时可以正常运行？ [英] Program OK outside debugger, SIGILL under debugger when stepping?
问题描述
我试图在BeagleBone Black上调试一个程序。在调试器外部，它产生了不正确的结果，但没有 SIGILL 。它也可以在没有断点的调试器下运行。但是，它会生成一个 SIGILL ，并在步进时设置一个断点。程序和库不使用 SIGILL - 基于CPU的特征探测器。然而，我不知道GDB在干什么。
在调试器中，我看到：
<$ p $
（gdb）r
启动程序：/ home / cryptopp / $ g $ b $ main
在0x26f20的断点1：file test.cxx， test.exe
test.cxx中的断点1，main（argc = 0x1，argv = 0xbeffea54）：22
22字节键[16] = {0};
（gdb）n
23字节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）
编程接收到的信号SIGILL，非法指令。
0x00026d5c在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
单步直到退出函数_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_，
没有行号信息。
程序以SIGILL信号，非法指令终止。
该程序不再存在。
和：
（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>&）
我试图寻找这个问题，但我一直无法找到一个命中。我得到了太多的噪音。
当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
$ b $
$ $ $ $ $ $ $ $ $ $ -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
$ b $ cat / proc / cpuinfo
处理器：0
型号名称：ARMv7 Processor rev 2（ v7l）
BogoMIPS：996.14
特性：half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU执行者：0x41
CPU架构：7
CPU变量：0x3
CPU部分：0xc08
CPU修订版：2
硬件：通用AM33XX（展开设备树）
版本：0000
序列号：0000000000000000
和
$ b $ pre $ 断点1，main（argc = 0x1，argv = 0xbeffea54）at test.cxx：22
22字节键[16] = {0};
（gdb）n
23字节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）
编程接收到的信号SIGILL，非法指令。
0x00026d5c在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
函数main（int，char **）的汇编代码转储：
0x00026f10< + 0> ;: push {r4，r7，lr}
0x00026f12 + 2：sub.w sp，sp，＃916; 0x394
0x00026f16< + 6> ;:加r7，sp，＃16
0x00026f18< + 8> ;:加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> ，＃4
0x00026f2a< + 26> ;: movs r2，＃0
0x00026f2c< + 28> ;: str r2，[r3，＃0]
0x00026f2e< + 30>：添加r3，＃4
0x00026f30< + 32> ;: movs r2，＃0
0x00026f32< + 34> ;: str r2，[r3，＃0]
0x00026f34< + 36> ;：增加r3，＃4
0x00026f36 <+ 38>：movs r2，＃0
0x00026f38 <+ 40>：str r2，[r3，＃0]
0x00026f3a< + 42>：增加r3，＃4
0x00026f3c< + 44>：add.w r3，r7，＃680; 0x2a8
0x00026f40< + 48>：movs r2，＃0
--- Type< return>继续，或者q< return>退出---
0x00026f42 <+ 50>：str r2，[r3，＃0]
0x00026f44 <+ 52>：加r3，＃4
0x00026f46 <+ 54> ;：movs r2，＃0
0x00026f48< + 56> ;: str r2，[r3，＃0]
0x00026f4a< + 58> ;:增加r3，＃4
0x00026f4c< + 60> ;: movs r2，＃0
0x00026f4e< + 62> ;: str r2，[r3，＃0]
0x00026f50< + 64> ;:加上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）>
---类型<返回>继续，或者q< return>退出---
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
...
感谢@ ks1322，this是已知的GDB /内核错误。请参阅 GDB在调试ARM SMP双核系统上的多线程程序时崩溃 GDB问题跟踪器。
据Debian BTS称，这也是一个已知问题。请参阅Debian BTS中的 SIGILL在应用程序中加入应用程序时。
这个错误被重新填充，希望它可能在未来一两年的某个时间内得到修复。请参阅由于GDB / Kernel生成的SIGILL导致的GDB崩溃
这就是我鄙视Debian的bug报告系统的原因。东西得到报道，然后它就会腐烂。没有什么固定的。
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.
这篇关于程序在调试器外部调试程序时可以正常运行？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
