0

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.
bhavs
  • 2,091
  • 8
  • 36
  • 66
  • 1
    Those options you mention are for cl, not gcc? If so why don't you use windbg or the debugger inside Visual Studio? They might do a better job in debugging a windows binary – stijn May 20 '16 at 06:40
  • @stijn yes the options that I have mentioned are for CL and not for gcc, I have tried with windbg ( realised that the command window was displaying assembly level instructions which I don't understand and since the private symbols were not loaded I was unable to set breakpoints there wither ) The comfort level is slightly higher with gdb. Unfortunately we have a exe which should be supported too – bhavs May 20 '16 at 07:20
  • Since you have cl, you likely have VS as well (unless you used one of those brand new 'just C++ toolset' thingies)? I'm fairly sure the comfort level of it's debugger is similar to gdb's, except that it's all in a gui instead of on the commandline. – stijn May 20 '16 at 10:29
  • Related: [The g++'s -g option equivalent to VS2010 cl compiler](http://stackoverflow.com/questions/4659754/the-gs-g-option-equivalent-to-vs2010-cl-compiler). It says that `cl` with `-Zi` and `link` with `-debug` are what's needed. Is there a pdb file in the same directory as the setup.exe file? – Mark Plotnick May 20 '16 at 14:47
  • @MarkPlotnick yes I have added the pdb file to the same directory as the executable; even then I do any see any difference as compared the status reported above – bhavs May 23 '16 at 07:00

1 Answers1

0

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.

Castor C Godinho
  • 48
  • 9