Home

hi. i'm going to keep notes here and hopefully if necessary this wiki will let me cut them out into later

debugging methods:

• printfs 32, 64, and process environments support rprintf, which doesn't attempt to hew very closely to the standard printf, but does support % formats and varargs, and allows modules to register their own single character formatters. '%v' is interesting in that its supposed to print any value which is dynamically tagged (i.e. tuples and their associated types). '%p' prints a pointer of the native type.

• fault reports. if you get past initializing the interrupt system, a fault should dump the current register file and the tail of the stack

• gdb stub. if you get up into user space, you can enable the remote gdb stub. instructions should be added here.

• set breakpoints and watch points directly. x86_64/breakpoint.c can be called directly from C to generate a trap when an instruction is fetched, a read, or write is performed.

- qemu based debugging
  - '-d int -D foo' will generate a report all of interrupts into the file 'foo'.
     the format of the register file gives you a good hint what mode the processor
     is in. this report isn't generated when kvm is enabled

  - '-s -S' turns on the qemu gdb stub (at :1234). the processor starts halted
     before the bios. set a breakpoint at the generated address for stage2:run64,
     single step until it complains about the returned context being too large
     (g packet reply too long). 'disconnect', 'set architecture i386:x86-64:intel',
     'target remote :1234', and you can continue execution up into stage3. this
     also isn't supported when running with kvm.

  - instrumenting qemu. if you're at a loss as to why the virtio driver isn't
    responding, you can check out a copy of qemu, add printfs, and go to town.
    qemu has alot of internal strata, so expect to spend a while tracking
    down the control flow, but introspecting the 'hardware' can be super
    helpful.