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.
Related
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
I keep getting "No symbol table is loaded" error while working on my GDB session.
I complied my source files using the following command :
$ gcc -g -Wall -o test exc4.3_modulus.c getop.c stack.c
When I started my GDB session as:
$ gdb test -tui
and tried to add a break point at getop function inside getop.c as
(gdb) b getop.c:getop
GDB is showing the following error:
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or n)
I browsed over stackoverflow and found this thread
[gdb: "No symbol table is loaded"
As suggested in the thread and in the gdb session I tried
(gdb) file test
But what I get as an outcome is not an improvement over the scenario
Reading symbols from /usr/bin/test...(no debugging symbols found)...done.
and problem with the break point still persists.
Can anyone point me out where I am going wrong? I am new to GDB. So an proper explanation would always be greeted thankfully.
PS : The problem is solved after I updated my GCC and GDB.
I am using gdb for debugging C project source code. I compile as shown:
./configure --enable-debug CFLAGS="-g -o0"
make --debug=a
I want to debugging stop at specific file. So when I set break point by using
(gdb) break main.c:672
It says:
No source file named main.c.
Even when I pass specific function name (in main.c file) to break . it says: such function not defined.
My current directory has this main.c file. I am using Cygwin on Windows. When I set break point by using
(gdb) break main
It set break point at a main function of Cygwin file, not in my source code.
how can I fix my first problem?
just curious, how to avoid second problem, if there is same function name within Cygwin files and my source code?
When you compile your .c file, make sure you use:
gcc filename.c -g
gdb <binary name>
Search for load debugging symbols done or not?
If not:
gdb) symbol-file <path-of-symbol-file>
you can find symbol file in obj directory
If you're compiling with -g and still not able to set a breakpoint, try adding raise(SIGTRAP) in your main(), run the process in gdb, then set the breakpoint you want again after it hits the SIGTRAP.
Crucial is gcc parameter -g during compilation.
Everything else is secondary.
See breakpoints in GDB
I also encountered with similar problem earlier. I just deleted .metadata folder and imported the particular project again and that work well.
Whenever you have to use GDB, type the following in command line
gcc -g -o outputfile sourcefile.c
Now type
gdb -tui outputfile
and then enter the break command
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
without -g flag:
(gdb) break main
Breakpoint 1 at 0x8048274
with -g flag:
(gdb) break main
Breakpoint 1 at 0x8048277: file example.c, line 31.
I vaguely know -g option stores the symbol table information.
What does the -g option exactly do?
Is there any way I can look at this symbol table?
-g (for gcc) stores debugging information in the output files so that debuggers can pick it up and present more useful information during the debugging process. Exactly what gets stored can depend a great deal on the environment you're running in.
One way to look at what this consists of is to use objdump with the --debugging option (or its equivalent short form -g which matches gcc).
The -g command line option asks the compiler to emit additional debugging information; on Linux, the format is DWARF 2, but other platforms may have different defaults -- stabs was more common, once upon a time.
readelf --debug-dump can be used to dump the debugging information itself if you're curious in what it adds -- you can see the entire program source in the .debug_info section, for example.