NewsForumsCodeLogsGallerySpecsSearch

Debigging a C++ static library running in BlitzMax

Archives Forums/Linux Discussion/Debigging a C++ static library running in BlitzMax

JoshK(Posted 2013) [#1]
I've been lucky in that both Visual Studio and Xcode are able to debug a C++ static library running in a BlitzMax application. Otherwise, it would have been impossible to developer the Leadwerks editor.

I have a similar setup running in Linux with Code::Blocks and GCC. However, when I try to debug the static library by running a BlitzMax application that imports it, I am unable to stop at breakpoints. It says no debugging symbols are found, which is fine for the BlitzMax code, but the static lib should still be debuggable.

Here is the program output:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug Static Library (x86)
Adding source dir: /home/josh/Applications/Leadwerks/Engine/Projects/Linux/
Adding source dir: /home/josh/Applications/Leadwerks/
Adding file: ../../../Editor/Leadwerks.debug
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
(no debugging symbols found)...done.
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04



JoshK(Posted 2013) [#2]
I did some more fiddling round, and the processes are communicating. Unfortunately Code::Blocks does not stop on any breakpoints:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug Static Library (x86)
Adding source dir: /home/josh/Applications/Leadwerks/Engine/Projects/Linux/
Adding source dir: /home/josh/Applications/Leadwerks/
Adding file: ../../../Editor/wintest.debug
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from /home/josh/Applications/Leadwerks/Editor/wintest.debug...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Child process PID: 16753
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()



JoshK(Posted 2013) [#3]
I uploaded a test project here:
http://www.leadwerks.com/post/MyLib.zip

The Code::Blocks project (MyLib.cbp) is configured to build a 32-bit static library. The application MyApp.debug will load this library and call one function. The project should have a breakpoint set in the SampleAddInt() function. MyApp.debug will also open a MaxGUI window, just to prove that it actually ran.

When I run this app from Code::Blocks (Debug > Start menu), it is unable to stop at the breakpoint.


JoshK(Posted 2013) [#4]
I am able to get it to work using a shared object. BlitzMax can load Linux shared objects just like DLLs and retrieve their function pointers. When the Code::Blocks debugger is run in this manner, it is able to stop at breakpoints and display variable values in the program:
Import "-ldl"

Const RTLD_LAZY:Int=1

Extern "c"
	Function dlopen:Byte Ptr(path$z,Mode:Int)
	Function dlsym:Byte Ptr(handle:Byte Ptr,name$z)	
EndExtern

Local handle:Byte Ptr=dlopen("./MyLib.so",RTLD_LAZY)
Global SampleAddInt:Int(i1:Int,i2:Int) = dlsym(handle,"SampleAddInt")

Print SampleAddInt(10,20)

End

However, I would like to be able to debug a static library. The Leadwerks C API is large and duplicating all those externed functions would be a big hassle.


dawlane(Posted 2013) [#5]
Now that I have finally got my system restored after a installing the wrong version of libstdc++-dbg and not having an internet connection for 24 hours. I though I would have a play around and it looks like to me that all the symbols are being stripped by bmk. So you will have to edit bmk_util.bmx at line 348 and remove the option -s and then rebuild bmk.

To prove it use
file MyApp.debug
You should see something like below on the standard bmk build.
MyApp.debug: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x9522433e7066e2abf6f61c6ac4cdf3b318ccd5cf, stripped

With option -s removed the same command will show
MyApp.debug: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x5a95b72c58857b72bb7b7bbb35d5c47509ebe504, not stripped

The down side is that you will have to restore the original bmk when you want to release the application.
I'm surprised skid hasn't said something about it.

Edit: Ran the sample application and breakpoints are a working. bmk needs a bit of a rewrite me thinks so the a debug build leaves symbols in but removes them when a release build is made.

bmk_util.bmx should only need this minor alteration at line 348 and on additional line.
cmd:+" -m32 -Os -pthread"
If Not opt_debug Then cmd:+" -s"

And for some reason find no longer is doing the above on my machine use command nm instead to get a symbol list.


Derron(Posted 2013) [#6]
just use the command "file"... find is for finding files.

Maybe your brain slowed down during your 24h internet connect loss ;-).


bye
Ron


dawlane(Posted 2013) [#7]
@Derron you must be right it. God knows where I got the idea it was find from.


JoshK(Posted 2013) [#8]
Thanks that works!

This whole process has been a real act of faith. Very glad to have the Blitz community to help.


JoshK(Posted 2013) [#9]
Make sure you use the -g flag. If you use -ggdb it won't work.


dawlane(Posted 2013) [#10]
If you use -ggdb it won't work.
Now that is strange as that flag should generate symbols that are 100% compatible with gdb.

Ideally bmk needs to be re-worked so that a CCOPTS string can be passed as a parameter.

Very glad to have the Blitz community to help.
Don't forget we will all be expecting discounts ;-)


JoshK(Posted 2013) [#11]
Maybe not. It took me a while to realize you actually have to hit "Continue" when the program starts, as GDB pauses the program upon connecting to it. How bizarre.