This is on Ubuntu 12.04, GDB version GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
The application I work on does dump core more times than I care to. When I start gdb as follows, I don't get any usable backtrace.
gdb --core <path to core dump>
GDB does show the full path of the process that caused the core dump along with command line arguments.
When on the gdb prompt, if I execute commands
file <path to executable>
core-file <path to core dump>
I do get a usable backtrace.
What is the difference between --core command line option and core-file command executed from the gdb prompt?
Is there any way I can do this in the command line? After all, gdb does know the path to the executable and core file name.
Is there anyway I can do this in command line.
Yes: gdb /path/to/exe /path/to/core
My main interest is why does gdb behaves differently.
It doesn't.
Most UNIX systems, in order to conserve disk space, do not dump file-backed read-only pages (such as program code) into the core file -- that code is already on disk, so why write it again? (This is actually configurable: see man core and coredump_filter).
But these read-only pages contain symbols (what you see in nm and in backtrace output), so if you don't tell GDB where the executable file is, then it can't produce a meaningful backtrace.
After all, gdb does know the path to executable
No, it does not.
The kernel records incomplete info about the executable which produced the core. That info is unreliable:
./a.out and there is absolutely no guarantee that your current directory is the same at GDB analysis time as it was when the executable was invoked, andelf_prpsinfo.pr_fname[], and anything longer than that will be truncated.