mmozeiko
If that stepping thing happens at start of program then that is because of special SDL main entry point. Your "main" is not the real main function. SDL does "#define main SDL_main" and then provides its own real "main" function. That's why debugger goes to assembly or/and asks for missing source file when you start executing program. SDL does this to execute some special initialization code before main starts to execute. Your options are a) download SDL source corresponding to SDL library you use and point debugger to them, b) compile SDL from source and link with libraries from this compilation and debugger will be able to find source code, c) don't start program by stepping into real "main" (from SDL), put a breakpoint on your "main" function (actually SDL_main) and run the program till it hits breakpoint, only do the stepping afterwards.
mmozeiko
That sounds like you are debugging optimized binary. Optimizer typically rearranges code a lot so asm instructions next to each other may come from lines that are far apart in source code.
I just downloaded David's SDL port and tried compiling and debugging day 18. It compiled without any modification to build/source and I could run, step and put breakpoints in Nevimer without problems. Of course, stepping into SDL functions goes to asm, that's expected.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | #!/bin/bash mkdir -p ../build pushd ../build #CommonFlags="-DDEBUG -g -O2 -Wall -Werror -Wno-write-strings -Wno-unused-variable -Wno-unused-but-set-variable -Wno-unused-function -Wno-sign-compare -Wno-unused-result -Wno-strict-aliasing -std=gnu++11 -fno-rtti -fno-exceptions -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1 -DHANDMADE_SDL=1" CommonFlags="-DDEBUG -g -Wall -Werror -Wno-write-strings -Wno-unused-variable -Wno-unused-but-set-variable -Wno-unused-function -Wno-sign-compare -Wno-unused-result -Wno-strict-aliasing -std=gnu++11 -fno-rtti -fno-exceptions -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1 -DHANDMADE_SDL=1" # Build a 64-bit version c++ $CommonFlags ../code/handmade.cpp -fPIC -shared -o handmade.so.temp mv handmade.so.temp handmade.so #c++ $CommonFlags ../code/sdl_handmade.cpp -o handmadehero.x86_64 -ldl `../code/sdl2-64/bin/sdl2-config --cflags --libs` -Wl,-rpath,'$ORIGIN/x86_64' c++ $CommonFlags ../code/sdl_handmade.cpp -o handmadehero.x86_64 -ldl `/usr/bin/sdl2-config --cflags --libs` -Wl,-rpath,'$ORIGIN/x86_64' # Build a 32-bit version #c++ -m32 $CommonFlags ../code/handmade.cpp -fPIC -shared -o handmade.so #c++ -m32 $CommonFlags ../code/sdl_handmade.cpp -o handmadehero.x86 -ldl `../code/sdl2-32/bin/sdl2-config --cflags --libs` -Wl,-rpath,'$ORIGIN/x86' #Copy SDL into the right directory. if [ ! -d "x86_64" ] then mkdir -p x86_64 cp /usr/lib/libSDL2-2.0.so.0 x86_64/ fi #if [ ! -d "x86" ] #then #mkdir -p x86 #cp /usr/lib32/libSDL2-2.0.so.0 x86/ #fi popd |
ofalltrades
I'm on a Mac, but this may be almost helpful. CLion is better than Xcode for debugging, but for some poor reason, it does not have the ability to view raw memory. So there's that. Since CLion is available on Linux, it is at least worth a gander.
theGiallo
I recently got to know about Visual Studio Code. It seems to me something like SublimeText or Atom, qith the debugging capabilities of VS. I still have to try it. It can use both gdb and lldb.
Some links:
https://code.visualstudio.com/docs/editor/debugging
https://code.visualstudio.com/docs/languages/cpp
https://code.visualstudio.com/docs/setup/linux
If it really has all the debugging features of VS Casey could think about moving to linux :P
Disclaimer: to the joy of all the Handmade people it uses Node.js :|
Oh, also I remember that Valve suggested to use QTCreator I think in this talk in 2014:
https://www.youtube.com/watch?v=xTmAknUbpB0
http://media.steampowered.com/apps/steamdevdays/slides/debugging.ppt
------
Oh crap... there were 3 pages... I didn't notice the "1 2 3" links...
VS code had already been posted https://hero.handmade.network/forums/code-discussion/t/228/p/6277
my bad :[
theGiallo
I just have installed it, together with the c++ plugin (and a vim-emulator plugin!), and to me it seems to be debugging like VS.
You just have to open a directory, click on the debug mode button and click play. It will create a launch file and ask you to fill the executable path part. Then you are ready to go.