emptyhead41 wrote: ↑Mon Feb 04, 2019 6:34 pm
@phkb and @another_commander. Have you guys got an environment set up to be able to compile the code from your code editor and/or do step-through debugging and breakpoints? I'm basically looking to step through the code to see what it's doing - i'm not familiar with objective C and seeing it in action might help me figure out what it's doing.
I always compile outside of the editor, using 'make debug=no' or 'make debug=yes', depending on how low level debugging is necessary. Stepping through the code and breakpoints are handled with the GNU Debugger (gdb), which is included in the environment. A normal session with gdb goes usually one of two ways:
1) When trying to debug a crash:
- From the DevEnv shell, cd to the folder with the Oolite binary:
cd <rootOolitePath>/oolite.app
- Then, run gdb and tell it to load up the Oolite executable:
gdb oolite.exe
- Run the game:
run
- Get it to the point of crash. Instead of a CTD or the "Application has stopped working and Windows is shutting it down, yo" window, you will see something like "Program received SIGSEGV at 0xdeadb00b" in the shell and see the gdb prompt. At this point, you just type "bt" and you will receive the backtrace leading up to the point of crash.
2) When setting and using a breakpoint:
- First two steps same as above
- Before running the game set a gdb breakpoint using the break command, e.g.
break src/Core/Entities/PlayerEntity.m:500, which sets a breakpoint at line 500 of the file named PlayerEntity.m.
- Run the game:
run
- When the program flow reaches line 500 of PlayerEntity. execution will break. You can then use other gdb commands to set values to variables, step through the code either by line or by function, watch variables as they change, retrieve backgtrace if required etc. Check out resources like
this one for more information on how gdb is used and what commands are available.
Be aware that running the game through gdb is painfully slow due to the way memory is tracked during program execution. Load times are extremely long compared to running outside of gdb and frames per second drop by almost one third. Quitting the debugging session is as simple as executing the
quit command in the gdb prompt.
Yes, it is not simple, it requires some studying and is most definitely not as user friendly as Visual Studio. But it works across both Windows and Linux alike. Hopefully this helps and feel free to ask if you get stuck.
