Debugging a library

[johne53]

I have a C::B workspace which builds a library (shared object). The library is then linked to several executables which are all in their (separate) workspaces. I need to debug the library which in turn, requires me to run one of the executables. This is simple enough if the library and executable are part of the same workspace but in this case, they aren't.

How do I specifiy an executable to run, so that when I press F8, the debugger can start? I assumed that "attach to process" might do the trick - but although C::B goes through the motions, I get this output from the debugger (after the symbols have been loaded):-

(gdb)
>>>>>>cb_gdb:
> show version
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:

and then the running application freezes (i.e. becomes unresponsive to mouse clicks etc). Is there any alternative way to specify the executable? Or is it possible to load two workspaces simultaneously, so that I can run one while watching variables and break points in the other??

[Edit...] Some further information...  I just realised that after attaching to a process, I need to select Debug->Continue which brings the external process back to life (in fact, it seems to restart it). However, this only works if I haven't set any break points. If I set some break points, Debug->Continue shuts the external process down but never re-starts it. Is there a better way to do this?

[Jenna]

Did you try to specify the host-application for your target in "Project -> Set program's arguments..." ?

[killerbot]

while reading this often called question, maybe it could be interesting to :

- put an entry for this in the debug menu ?
- no longer store this in the project file, but in a MyProject.debug file [interesting for version control systems, so no need to checkout/checkin the cbp file]

Just a wild idea ;-)

[johne53]

Did you try to specify the host-application for your target in "Project -> Set program's arguments..." ?

Apologies - I knew I'd seen a field somewhere called "Host application" but I couldn't remember where.

while reading this often called question, maybe it could be interesting to :

- put an entry for this in the debug menu ?
- no longer store this in the project file, but in a MyProject.debug file [interesting for version control systems, so no need to checkout/checkin the cbp file]

Just a wild idea ;-)

It might be simpler to rename the menu item called "Set programs arguments" and call it "Set debug host & arguments"

[johne53]

In any case, after about 5 weeks of trying to use this feature it's only worked in a handful of cases. Typically I select the library (usually a shared object) that I wish to debug. I then select Project->Set Programs' Arguments->Host Application. I navigate to the target executable (Debug version) and I uncheck the box that says "This target provides the project's main executable" (is that right?)

I then press F8 to start the debugger. In the vast majority of cases, the debugger (gdb) starts and I get to the "run" stage. The debugger output window then shows this error:-

No executable specified, use `target exec'

Am I doing something wrong?

[johne53]

Seems to be a lot better after upgrading to the latest nightly build.

[johne53]

In any case, after about 5 weeks of trying to use this feature it's only worked in a handful of cases.

[...]

Am I doing something wrong?

Apart from the problem I described in this thread, one of my major problems was that I could never (well, almost never) get break points to work satisfactorily with C::B and Cygwin. Eventually, this caused me to abandon both technologies. However, fogged by the mists of time, I decided yesterday to revisit them both.

As often happens when one abandons a tool and comes back to it much later, the reason for the original problem now seems blindingly obvious. Let's say I was debugging a project and wanted to set a breakpoint in the following source module:-

F:\MyProj\libs\soundtouch\FifoSampleBuffer.cpp

It's important to remember that when using C::B with Cygwin, you have to use the Windows build of C:B. Naturally, this interprets the above as a DOS-style path. However, you're trying to debug your app using Cygwin/gdb which (also naturally) has no understanding of DOS paths. This causes the debugger to fail when trying to set a break point in the above module. For Cygwin/gdb to work, the path would have to be passed to it in the form:- /cygdrive/f/MyProj/libs/soundtouch/FifoSampleBuffer.cpp

How simple would it be for C::B to carry out this conversion automatically? In other words if the selected compiler was Cygwin/gcc, DOS-style paths would get intelligently converted to Cygwin-style paths before being sent to the debugger. As another example, if I tried to set a break point in C:\cygwin\home\johne53\MyProj\SomeSourceFile.cpp (and the selected compiler was Cygwin gcc) C::B would intelligently convert the path to its Cygwin equivalent (namely, /cygdrive/c/cygwin/home/johne53/MyProj/SomeSourceFile.cpp) before sending it to gdb.

I can't be 100 percent certain but my gut instinct is that this would solve a major incompatibility problem between CodeBlocks and Cygwin. Also, I'd be happy to beta test this change if the dev team thinks it might be worth trying.