Why does GDB need the executable as well as the core dump

core-dumpgdb

I'm debugging using core dumps, and note that gdb needs you to supply the executable as well as the core dump. Why is this? If the core dump contains all the memory that the process uses, isn't the executable contained within the core dump? Perhaps there's no guarantee that the whole exe is loaded into memory (individual executables are not usually that big though) or maybe the core dump doesn't contain all relevant memory after all? Is it for the symbols (perhaps they're not loaded into memory normally)?

Best Answer

The core dump is just the dump of your programs memory footprint, if you know where everything was then you could just use that.

You use the executable because it explains where (in terms of logical addresses) things are located in memory, i.e. the core file.

If you use a command objdump it will dump the meta data about the executable object you are investigating. Using an executable object named a.out as an example.

objdump -h a.out dumps the header information only, you will see sections named eg. .data or .bss or .text (there are many more). These inform the kernel loader where in the object various sections can be found and where in the process address space the section should be loaded, and for some sections (eg .data .text) what should be loaded. (.bss section doesn't contain any data in the file but it refers to the amount of memory to reserve in the process for uninitialised data, it is filled with zeros ).

The layout of the executable object file conforms to a standard, ELF.

objdump -x a.out - dumps everything

If the executable object still contains its symbol tables (it hasn't been stripped - man strip and you used -g to generate debug generation to gcc assuming a c source compilation), then you can examine the core contents by symbol names, e.g. if you had a variable/buffer named inputLine in your source code, you could use that name in gdb to look at its content. i.e. gdb would know the offset from the start of your programs initialised data segment where inputLine starts and the length of that variable.

Further reading Article1, Article 2, and for the nitty gritty Executable and Linking Format (ELF) specification.

Update after @mirabilos comment below.

But if using the symbol table as in

$ gdb --batch -s a.out -c core -q -ex "x buf1"

Produces

 0x601060 <buf1>:    0x72617453

and then not using symbol table and examining address directly in,

$ gdb --batch -c core -q -ex "x 0x601060"

Produces

0x601060:   0x72617453

I have examined memory directly without using the symbol table in the 2nd command.

I also see, @user580082 's answer adds further to explanation, and will up-vote.

Related Solutions

Dump process core without killing the process

The usual trick is to have something (possibly a signal like SIGUSR1) trigger the program to fork(), then the child calls abort() to make itself dump core.

from os import fork, abort
(...)
def onUSR1(sig, frame):
    if os.fork == 0:
        os.abort

and during initialization

from signal import signal, SIGUSR1
from wherever import onUSR1
(...)
signal.signal(signal.SIGUSR1, wherever.onUSR1)

Used this way, fork won't consume much extra memory because almost all of the address space will be shared (which is also why this works for generating the core dump).

Once upon a time this trick was used with a program called undump to generate an executable from a core dump to save an image after complex initialization; emacs used to do this to generate a preloaded image from temacs.

Can anything useful be done with a truncated core

This blurb on the Sun Studio 12 website would seem to imply that they're basically useless.

excerpt - http://docs.oracle.com/cd/E19205-01/819-5257/blabs/index.html

If Your Core File Is Truncated

If you have problems loading a core file, check whether you have a truncated core file. If you have the maximum allowable size of core files set too low when the core file is created, then dbx cannot read the resulting truncated core file. In the C shell, you can set the maximum allowable core file size using the limit command (see the limit(1) man page). In the Bourne shell and Korn shell, use the ulimit command (see the limit(1) man page). You can change the limit on core file size in your shell start-up file, re-source the start-up file, and then rerun the program that produced the core file to produce a complete core file.

If the core file is incomplete, and the stack segment is missing, then stack trace information is not available. If the runtime linker information is missing, then the list of loadobjects is not available. In this case, you get an error message about librtld_db.so not being initialized. If the list of LWPs is missing, then no thread information, lwp information, or stack trace information is available.If you run the where command, you get an error saying the program was not “active.”

Best Answer

Related Solutions

Dump process core without killing the process

Can anything useful be done with a truncated core

If Your Core File Is Truncated

Related Question