I have been given a binary file with embedded C code which I cannot see when I run it in the GDB GCC Debugger. I imagine the C code has been hidden by the compilation / formation of the binary code. I have tried the following:
gdb> file myFile
gdb> list main
The output I get is:
myFile.c: No such file or directory
I know there is code written in C in this binary file. The executable runs when I type ./myFile
I have installed 32-bit libraries as this is needed for this situation and I'm running Ubuntu 16.04
Any help is appreciated.
It could be are a compilation issue. Try to look option for debugging
$ gcc -g myFile.c -o myFile
$ gdb myFile
(gdb) list main
If you compile without "-g" option, the debugger will never show you th C code but only the assembly code.
In your case, if you run these commands, you will see the disassembled code
(gdb) info file
Then take the address of the entry point
Entry point: 0x(address)
For show disassembly code
(gdb) break 0x(address)
(gdb) run
When the breakpoint gets caught
(gdb) x/20i $pc
Related
I was trying to learn how to use gdb on core dumps.
Here is the code:
int main()
{
return 1/0;
}
This is the gdb output, when I run gdb a.out core:
warning: exec file is newer than core file.
[New LWP 3121]
Core was generated by `./crash'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x00000000004004fc in ?? ()
(gdb) bt
#0 0x00000000004004fc in ?? ()
#1 0x0000000000400500 in ?? ()
#2 0x00007f6ea0945b97 in ?? ()
#3 0x0000000000000000 in ?? ()
What are ?? in the backtrace? How can I resolve them?
Those ?? are usually where the name of the function is displayed. GDB does not know the name of those functions and therefore displays ??.
Now, why is this happening? Depends. GCC compiles including symbols (e.g. function names and similar) by default. Most probably you are working with a stripped version, where symbols have been removed, or just with the wrong file.
As #zwol suggests, the line you see warning: exec file is newer than core file is an indication of the fact that something else is going on that you don't show in your question. You are working on a core dump file generated by the crashed executable, which is outdated.
I would suggest you to re-compile the program from scratch and make sure that you are opening the right file with GDB. First produce a new core dump by crashing the new program, then open it in GDB.
Assuming the following program.c:
int main(void) { return 1/0; }
This should work:
$ rm -f core
$ gcc program.c -o program
$ ./program
Floating point exception (core dumped)
$ gdb program core
Reading symbols from program...(no debugging symbols found)...done.
[New LWP 11896]
Core was generated by `./program'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x000055d24a4cd790 in main ()
(gdb) bt
#0 0x000055d24a4cd790 in main ()
(gdb)
NOTE: if you don't see (core dumped) when running the process that means that a core dump was not generated (which leaves you with the old one). If you are using Bash, try running the command ulimit -c unlimited before crashing the program.
What does ?? in gdb backtrace mean
It means that GDB has no idea to which code the addresses in backtrace: 0x04004fc, 0x0400500, etc. correspond.
and how to get the actual stack frames?
That depends on why this is happening. There are two common scenarios:
You are debugging the wrong executable.
One way this could happen is when you compile with optimization, e.g. gcc -O2 main.c -o crash, let the program dump core, then recompile with debugging (e.g. gcc -g main.c -o crash) and try to debug "old" core dump with "new" executable.
Don't do that. Instead, compile with optimization and debugging: gcc -O2 -g main.c -o crash.
P.S. This warning: warning: exec file is newer than core file is intended to warn you precisely about this case.
The other common cause is when you obtain a crash on a production system and try to debug it on a development one (given the addresses which you show this is unlikely to have happened here).
For that case, see this answer.
You did not compile with debug symbols - try adding -g to the compile line
I use the command gcc -std=gnu99 -g -pthread dotProduct_critical_ompi.c -I. to compile my C program and then use gdb to debug it with the command gdb dotproduct.
But the source file which gdb shows in terminal named dotProduct_critical.c is not the source file I compiled ( my source file is dotProduct_critical_ompi.c ). Why? Thanks for your help.
Update
The problem was solved after I remove the output file and recompile several times. But today, after I modified my source file, the error occured once more. And the method doesn't work any more. What can I do? (My source file is still dotProduct_critical_ompi.c)
the output of command gdb -batch dotproduct -ex "info sources" is:
after trying a couple of alternatives to debug a exe fairly unsuccessfully decided to try gdb to debug a executable on the windows env.
The options that are being used to compile the exe look like this
/nologo /Z7 /Zi /MT /W3 /GX /O2 /D /DEBUG
These are the options that I am using to load the executable into gdb
target exec setup
run -debug ( this is the option against which I would like to perform some debugging)
I need a way to either load the source/symbols into GDB since I am unable to set any valid breakpoints otherwise.
This is what I have tried, in order to set breakpoints ( other than the usual way)
(gdb) set breakpoint pending on
(gdb) break runInstaller.c:6318
No symbol table is loaded. Use the "file" command.
Breakpoint 2 (runInstaller.c:6318) pending.
(gdb) pwd
Working directory C:\
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> WinMain
2 breakpoint keep y <PENDING> runInstaller.c:6318
I have tried this to load the executable;
(gdb) file setup
Reading symbols from setup...(no debugging symbols found)...done.
It is due to the above errors I realise that the executable is not compiled with the debugging options, so it there a gcc -g equivalent in gdb or are there better way s of loading the symbols/source code into gdb.
Edit 1:
Whenever I try to add a breakpoint I see the following error:
(gdb) b main_helper
Function "main_helper" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 5 (main_helper) pending.
The setup file which you are currently using does not have the symbol table which is required to debug. When you are generating the executable binary you need to generate the symbol table as well.
Ex. when we are generating the executable file for a c program we compile with the argument -g.
gcc setup.c -o setup -g
-g tells the gcc compiler to generate the symbol table.
To create the .out executable, I have to enter:
$: make
$: myprogram.out name.ged
My program incorporates a command line argument, thus the "name.ged".
Whenever I run gdb after getting a segmentation fault (core dumped), I enter:
$: gdb a.out core
(gdb): bt
I then use the back trace command, and gdb returns:
#0 0x4a145155 in ?? ()
#1 0x08a16ce0 in ?? ()
I even tried using the up command t move up the stack, but still no luck. I can't tell which line in my program is giving me the seg fault. gdb works with my other programs that do not involve a Makefile and command arguments, so I'm wondering if my commands are incorrect.
Summarizing the comments (before anyone else does :).
Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.
In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.
CFLAGS= -g -Wall -Wextra
You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).
$ CFLAGS='-g -Wall -Wextra' make
I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.
CFLAGS='-Wall -Wextra'
Then, when you need it, put this in the makefile to make a debuggable executable:
CFLAGS+= -g
i am trying to gdb trietool to understand trietool source code.But it always failed to gdb.
step as below:
(1)./configure CFLAGS=-g
(2)make
and then cd /mnt/hgfs/code/libdatrie-0.2.5/tools,ls -lrt
and gdb trietool-0.2,it will report error as below
/mnt/hgfs/code/libdatrie-0.2.5/tools/trietool-0.2": not in executable format:
and gdb trietool-0.2.o,it is ok,and then type command b ../datrie/trie.c:289,it report
(gdb) b ../datrie/trie.c:289
No source file named ../datrie/trie.c.
But in fact there is trie.c file in datrie dir.
How to fix this issue to get gdb work?Do i miss sth?
Why gdb trietool-0.2 is not ok?
milan#milan:/mnt/hgfs/code/libdatrie-0.2.5/tools$ file trietool-0.2
trietool-0.2: Bourne-Again shell script text executable
/mnt/hgfs/code/libdatrie-0.2.5/tools$ file trietool.o
trietool.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped