0

Related:

What are the most common ways to debug a core dump file? The two ways that I have tried are using readelf:

$ readelf core -a

And then using gdb:

$ gdb file core

However, with gdb I don't get much information (at least not that I can make sense of). For example it shows:

Reading symbols from file...
(No debugging symbols found in file)
[New LWP 46778]
Core was generated by `./file'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000040100a in ?? ()
>>> bt
#0  0x000000000040100a in ?? ()
#1  0x0000000000000001 in ?? ()
#2  0x00007ffe342c3cbe in ?? ()
#3  0x0000000000000000 in ?? ()

What sense can someone make of that though? What would be an example of how the core file could be used to make sense of something?

David542
  • 104,438
  • 178
  • 489
  • 842
  • 1
    *(No debugging symbols found in file)* - so GDB doesn't have any symbol names, perhaps because you stripped the binary or didn't make any of your asm symbol names `global`. You can only look at register values and bytes in memory, and disassemble code. (And get a backtrace with numeric addresses). – Peter Cordes Oct 06 '20 at 04:31
  • @PeterCordes I see so basically a core file dumped from hand-written assembly without the corresponding DWARF is pretty useless for debugging, right? – David542 Oct 06 '20 at 04:34
  • Hardly. It was written by hand in asm so presumably you can understand how the program works by looking at the disassembly (maybe by looking at the commented source in another window). `layout reg` should still work, as should `disas`. You basically have access to everything you would if you ran the program inside GDB until it stopped on a SIGSEGV or whatever. You just can't single-step, rewind, or set a breakpoint earlier and restart. – Peter Cordes Oct 06 '20 at 04:38

0 Answers0