GDB problem

[peran]

Hi,

It seems I have a problem debugging my application. I have tried this on SE 2014 and the latest 2015 Beta 3 with the same outcome.

I'm trying to debug an application compiled with gcc 4.6.2 (mingw). The SE project is 'gnu c/c++' and the default gdb shipped with slickedit is used. All files are compiled as 'c' only.

When I launch gdb with Debug->Start I would expect the debugger to halt at main. Instead the application is executed until finished. If I place a breakpoint the same thing happens. Also, if I do ctrl+f10 on the line in interest the same thing.

I also tried to make a new 'gnu c/c++' (and C as language) default 'hello world' project. Compiled and launched gdb. Same thing.

Quite annoying. Some ideas are very welcome

OS: Windows 8 x64 (-> Really Win 10)
OS Version: 6.02.9200 
Memory: 48% Load, 7365MB/15343MB Physical, 8293MB/30703MB Page File, 410MB/134217727MB Virtual
Shell Information: C:\WINDOWS\system32\cmd.exe /q
Screen Size: 1600 x 1200, 1920 x 1080

Project Type: Gnuc
Language: .c (C/C++)
Encoding: Automatic

[Dennis]

GDB has a hard time with 32 vs 64-bit on Windows.  On other platforms, it handles the multiple targets pretty flawlessly, but on Windows, no such luck.  Since you are running the 64-bit distribution of SlickEdit, the GDB we ship was built as a 64-bit MingW executable, and thus is targeted for debugging 64-bit executables.

However, the default Cygwin and Mingw compilers generate 32-bit code.  There are 64-bit distributions, but I'm going to guess, based on your distribution being as old as GCC 4.6.2, yours is 32-bit.

Here's what you do to correct the situation:

1) Go to Debug > Debugger Options... > Configurations
2) Click + to add a new configuration.
3) Navigate to your cygwin installation directory /bin and select gdb.exe
4) Click "OK" to select it.
5) Then in the Configurations dialog, set the "Target Name" to something you can remember, like "Cygwin 32-bit GDB", and check "Default native debugging configuration".
6) Hit OK

And one more setting for safety, because Python pretty printing, especially with earlier releases of GDB, is very prone to hanging (because it pays no attention to limits or when variables are not initialized).

1) Debug > Debugger Options... > General
2) GDB Options > Enable Python pretty printing > OFF

The you should be all set.

[peran]

Hi,

Your help did the trick for my 'hello world' default project, but I still have the same problem with my main application.

In the meantime I upgraded the build tools to mingw64 - gcc 5.2.0 in an effort to get rid of this problem. GDB works with 'hello world', but still the same problem with my other application. However, a bug in the code (due to some type incompatibilities between old and new version of toolchain) caused an exception in the debugger and stopped at the line causing the problem). So, I guess something is working ok

I'm not sure what the difference between them is? The code I'm trying to debug is old, and has evolved from the mid 90's. It's 100k+ lines of C code and is running on an embedded platform. It is also possible to compile it so it will run on a regular pc platform in simulation mode - what I'm doing. There are a LOT of preprocessor defines, and Slickedit has helped me out a lot to get to know and analyze the code.

I'm not sure if it is relevant or not, but as an example of the preprocessor defines. The following is from the main entry point.
#ifdef STANDALONE
void my_main() {
   int argc;
#else /* not STANDALONE */
#ifdef CONCPU_PC_SIM
void main(int argc, char *argv[]) {
#else // !CONCPU_PC_SIM
void main() {
   int argc;
#endif // CONCPU_PC_SIM
#endif

Where only CONCPU_PC_SIM is defined.
 
If I use gdb directly (from mingw64\bin); gdb PCCsf40.exe // my compiled app
I get some errors with regards to pretty_printer in some python code. Probably related to the issue below.
But with gdb -nx PCCsf40.exe there are no errors. The output is Reading symbols <....>... done. The 'run' command will execute the application. 'info target' command will say the file type is pei-x86-64.

[Dennis]

A few things to check:

Does the code use shared libraries?  GDB can be stubborn about loading symbols from shared libraries.  Sometimes you have to coax it along manually (by using debug-send-command from the Slick-C command line after you step into the application).

Since you've switched compiler chains, are you using the 64-bit GDB that came with mingw64 or the one that we shipped, or the older 32-bit one I suggested you try using the older compiler chain.

Also, Debug > Start will not stop at main, it will simple start the debugger and run until you hit a breakpoint.  Debug > Step Into will step in, but it depends on the version of GDB whether a native step-in is supported, or if we have to simulate a step-in by setting a temporary breakpoint in main.

Finally, you can debug some of the problems with our GDB integration by turning on logging (Macro > Set Variable... > def_debug_logging = 1).  The log will be in <slickedit config>/logs/debug.log, search for "breakpoint" and you'll see the commands sent to set your breakpoints, and the events received from GDB to stop at breakpoints.  However, usually the most important thing in the log is the chatter at the beginning showing which GDB was invoked, and how GDB responded to setting the executable and the first -exec-run or the -exec-step command sent.

Remember to turn logging back off after you are done.

[peran]

I have used both your gdb and the one in mingw64 with the new toolchain. It works stepping into the code Single stepping works as well.

But I cannot set a breakpoint, or more correct it looks like I can. I am setting a breakpoint. Continues with the execution, but it runs until the end.

The debug information from debug.log was interesting:
debug[2015-10-16T00:11:39Z]  GDB command_reply: timeout=0
debug[2015-10-16T00:11:39Z]  GDB command_reply: command=-break-insert -f Src\\Pc_ezld.c:123
debug[2015-10-16T00:11:39Z]      GDB event: empty event packet
debug[2015-10-16T00:11:39Z]    GDB send: command=-break-insert -f Src\\Pc_ezld.c:123
debug[2015-10-16T00:11:39Z]  GDB command_reply: elapsed=0
debug[2015-10-16T00:11:39Z]      GDB event: &"No source file named Src\\\\Pc_ezld.c.\n"
debug[2015-10-16T00:11:39Z]      GDB event: ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="Src\\\\Pc_ezld.c:123",times="0",original-location="Src\\\\Pc_ezld.c:123"}
debug[2015-10-16T00:11:39Z]      GDB event: (gdb)
debug[2015-10-16T00:11:39Z]      GDB event: found (gdb) prompt
debug[2015-10-16T00:11:39Z]  GDB command_reply: reply=^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="Src\\\\Pc_ezld.c:123",times="0",original-location="Src\\\\Pc_ezld.c:123"}
debug[2015-10-16T00:11:39Z]  GDB command_reply: elapsed=0
debug[2015-10-16T00:11:39Z]      GDB event: empty event packet
debug[2015-10-16T00:11:39Z]GDB command_reply: DONE

I am trying to set a breakpoint at line 123 in pc_ezld.c, but to me it looks like it cannot find the file?

My files are organized as follows:
<root catalog> has slickedit project and workspace.
<root catalog>\Src has all C files
<root catalog>\Include has all header files
<root catalog>\Debug has object files and executable file

[Dennis]

I might be able to put a fix in for this, but I need to see the rest of your debug log.  I need to know how it came up with Src\\Pc_ezld.c instead of just using the filename alone.

Also, another experiment that would be helpful would be to issue the following commands from the SlickEdit command line:

debug-send-command -break-insert -f Src/Pc_ezld.c:123
debug-send-command -break-insert -f Pc_ezld.c:124

debug-send-command -break-insert Src/Pc_ezld.c:125
debug-send-command -break-insert Pc_ezld.c:126

[peran]

Sorry, but I totally missed your last edited reply - hence my late response. I can experiment as you suggest, and get back to you on this.

[Dennis]

I reproduced this problem on Windows and will put a fix in for the next Build.

[peran]

Thanks