Linux Standalone Debuggers

When I was looking for debuggers a few years ago, I tried Nemiver and it didn't really work, but I liked the fact that it was trying to be standalone... I'll try it again, maybe it's more done at this point!

- Casey
I have some issues with it when using the Handmade SDL port. When I step (F6) it jumps into assembly or it asks for an SDL source file that I don't have. Perhaps there's a setting I don't understand, or its a bug on my platform.

When I save the session and restart it, it doesn't remember the files I had open, nor remember the break points. That part isn't a deal breaker but it's a nuance.


Edited by Mór on
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.
Hey Casey,

I had the same struct-not-being-inspected problem on QtCreator and solved it by using this gdb option on startup:

set max-value-size 536870912

Add that line on QtCreator Tools->Options->Debugger->GDB->Additional Startup Options:

In my case, gdb was configured to not inspect structs larger than 64kb by default.

EDIT: You can also add that line to your .gdbinit if you like it that way better, just make sure QtCreator is configured to read it. Check 'Load .gdbinit file on startup'.

Best regards,
Daniel

Edited by Daniel on
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.


I found part of the problem. It was using sdl2-config and libSDL2-2.0.so.0 from David Gow's machine, so I redirected the paths in his build file. Now it's no longer asking for the SDL2 source files, but still jumps into assembly and gets stuck, even in the GameUpdateAndRender function.

Update
I tried debugging it as an external executable in Qt Creator and CLion and it worked okay, but debugging executables externally in both is horrible, as the stepper bounces all over the place. At this point I think its simpler to use the IDEs as they were designed to be used (with their project files), and if you like to use an external editor then use it.

Edited by Mór on
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.
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.


I just tried day 18 and it works well in Nemiver. The one causing problems is Kim Jørgensen's SDL port version 122. Instructions are here if you'd like to test it out for yourself:

https://hero.handmade.network/forums/game-discussion/t/1411

You are right there was an optimization flag set. I just assumed it wouldn't step as well. So now it steps well in CLion but Nemiver still has the problem of jumping into assembly and just now it locked my computer. It could have been because CLion was on at the same time. I don't know.

Here is the build script with some minor changes.

 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



Edited by Mór on
I've been using the VisualGDB plugin trial for Visual Studio. I use it for writing C for the raspberry pi. As far as I can tell all debugging features form VS work. Some of the more advanced ones I tried: data breakpoints, disassembly viewer, data viewer.

It looks like it can build with custom build scripts, as well as make systems. I used make, since it was the default. It supports both GDB and LLDB backends for debugging.

But it's a paid product, and will probably have to switch to something else when the trial is over.
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 :[

Edited by Gianluca Alloisio on
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.

Oh, I should say that CLion itself doesn't have a memory viewer, but here is a snippet of lldb stuffs that can be played around with in CLion's terminal: `me r -c 32 screenBuffer_ptr`. Type `help` to clarify the meanings. Either way, that is still a pain. I don't know what I will do about that. Maybe look at voltron. Anyone have any other suggestions for nicely viewing memory?

P.S. I wish this board supported markdown.

P.P.S. Also, Apple got rid of function and esc keys... what?

Edited by Jake Johnson on
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.


On their version 3 road map disassemble view is coming, so hopefully raw memory view will come with it.

https://blog.jetbrains.com/clion/2016/07/clion-2016-3-roadmap/

What the CLion team works on is partly dependent on what is voted for on their Youtrack. So if you want something send them an email and they will direct you to the place to vote for it.

Edited by Mór on
Oh, very cool. I got excited and downloaded the current EAP release, just to see. No dice.
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 :[


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.

Edited by Gianluca Alloisio on Reason: missing quotation made post misunderstandable
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.


I assume you mean CLion. If so, what C++ plugin are you using?

Edited by Mór on
No, not CLion but VSCode. The fact is that I replied to my message and thought it would be more visible. I should have quoted myself.