Unfortunately that is a lot of what you do while programming. This page collects some tips.
For debugging and diagnostics, it is smart to always have serial out enabled to another machine (whether in a VM or not). It becomes easy to log your own in-kernel/-driver/-server printf()s, and to interrogate the system about its state. See SerialOut for full details.
GDB within Minix isn't fully supported.
It is very convenient to debug Minix itself by attaching GDB to an emulator running it. VM-specific examples and general instructions follow.
debugStub.listen.guest32 = "TRUE" debugStub.hideBreakpoints = "TRUE" # Allows gdb breakpoints to work # really, prevent VMware (and GDB) to write INT3 into guest memory #debugStub.listen.guest32.remote = "TRUE" # Allows debugging from a different computer / VM instead of localhost. # The IP for remote debugging will be that of the host. #monitor.debugOnStartGuest32 = "TRUE" # Breaks into debug stub on first instruction (warning: in BIOS!) # This will halt the VM at the very first instruction at 0xFFFF0, # you could set the next breakpoint to break *0x7c00 to break # when the bootloader is loaded by the BIOS
Once you did the above
(gdb) target remote localhost:8832
Then you can already start following the thing here, instruction by instruction.
DBG=-g on the make line to enable this, verify it does what you want by adding
Setting breakpoints and watchpoints is easier if all addresses are unique. But because the same virtual address space is shared between many processes, this isn't usually true. To make your process get loaded at a unique location, tell the linker to link it to a high address. To do that, add
-Wl,-Ttext=0x800000 to the gcc link command line. E.g. in the VFS Makefile:
LDADD+= -lsys -ltimers -lexec -lmthread -Wl,-Ttext=0x800000