是否有可能debugging由没有gdb标志编译的可执行文件生成的核心文件？

是的你可以。 这并不容易。 我会给你一个例子。

可以说，我有以下程序称为foo.c ：

main() { *((char *) 0) = '\0'; } 

我将编译它，并确保没有符号：

 $ cc foo.c $ strip a.out $ file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped 

好吧，运行它的时间：

 $ ./a.out Segmentation fault (core dumped) 

哎呀。 似乎有一个错误。 开始一个调试器：

 $ gdb ./a.out core [..] Reading symbols from /tmp/a.out...(no debugging symbols found)...done. [..] Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. #0 0x0804839c in ?? () (gdb) bt #0 0x0804839c in ?? () #1 0xb7724e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #2 0x08048301 in ?? () 

嗯，看起来不好。 没有符号。 我们可以弄清楚发生了什么？

 (gdb) x/i $eip => 0x804839c: movb $0x0,(%eax) 

看起来像试图将一个值为0的字节存储到EAX寄存器指向的内存位置。 为什么失败？

 (gdb) p $eax $1 = 0 (gdb) 

它失败了，因为EAX寄存器指向一个内存地址零，它试图在该地址存储一个字节。 哎呀！

不幸的是，我没有指向任何好的教程。 搜索“gdb逆向工程”给出了一些有可能有用的零碎的链接。

更新：

我注意到这是关于调试客户的核心转储的评论。 当您将剥离的二进制文件发送给客户时，应始终保留该二进制文件的调试版本。

我会建议不剥离，甚至给源代码。 我写的所有代码都会通过源代码发送给客户。 我一直在客户方面面对一个无能的供应商，这个供应商已经提供了一个破碎的软件，但不知道如何解决这个问题。 它很烂。

这似乎实际上是这个问题的重复：

调试没有符号的核心文件

那里有一些额外的信息。

是的，你可以，这就是那些写错误的人，不幸的是，我没有我在大学学习的课程的幻灯片和文档，但是用reverse engineering或disassembly tutorials会给你一些起点。 也知道你在汇编代码中的方式是至关重要的。

我们的课程主要是基于一本书的第一章和第三章，但现在有一个新的版本

Computer Systems: A programmer's perspective by RE Bryant and DR O'Hallaron

它解释了计算机系统背后的基础知识，也使您对系统中程序的工作有了很好的了解。

另外当学习这一点时，请注意64位cpu具有不同于32位cpu的汇编代码，以防万一。

如果程序编译时没有-g标志，则不能调试核心文件。

否则你可以这样做：gdb executable corefile

更多你可以找到： http : //wwwpub.zih.tu-dresden.de/~mlieber/practical_debugging/04_gdb.pdf