is their a half-decent way to debug an OS

[earlz]

I would really like a debugging method in my OS and I heard that gbd supports external debugging through comports.. but how exactly does that work

and please don't tell me "just use bochs built-in debugger!" as it is really an ultra weak debugger

[shell]

Run your os on a different virtual machine. Not very hard, now is it?

[Brendan]

Hi,

I would really like a debugging method in my OS and I heard that gbd supports external debugging through comports.. but how exactly does that work

In general, there's a "stub" in the code being developed which acts like a client for GDB. GDB and this client use a special protocol to talk to each other. For details of this protocol, try some of these sites (or Google):

• http://shekel.jct.ac.il/cc-res/online-doc/gdb/gdb_105.html#SEC105
  http://davis.lbl.gov/Manuals/GDB/gdb_31.html
  http://www.embedded.com/1999/9911/9911feat3.htm

I'd also want to look at the files distributed with GDB - apparently it contains "pre-made" stubs and one is called "i386-stub.c".

BTW I've ever used GDB for OS development, so I'm not sure what problems you're likely to encounter - most of us use emulators and/or "printf debugging"...


Cheers,

Brendan

[earlz]

I've been using printf and assert debugging but it would be really nifty to be able to see your lines of code..

meh... I might even attempt to create some sort of simple debugger specially for an OS and use through com ports or lpt ports

[omin0us]

I use bochs for all my debugging. i have to build configurations that i switch between. one with the built in debugger enabled, that i use for low level debugging. stepping 1 instruction at a time and examining registers and stack values.

i also have a bochs build with remote gdb stub enabled. and then i can compile my kernel with symbols. run it in bochs. and connect with gdb
and debug my kernel line by line.

i can write up a little tutorial if you are interested in how to set that up.

[bluecode]

omin0us, I'm also interested in a tutorial, since I'm currently only using prints and the internal bochs debugger.

[viki]

Omin0us mayby the best way is not to create whole tutor at once but step by step. Actually I can't itch for it.

[inpherno]

I use this: http://fabrice.bellard.free.fr/qemu/
this: http://sourceware.org/gdb/
and this: http://sourceware.org/insight/

It all works nicely together and I can step through my code while viewing the C code and ASM. It's also got a memory viewer, so you can see if things are being written to memory correctly.

All you need to do is run qemu with -S -s in the command line, then connect with insight via remote debugging.

[AndrewAPrice]

I use this: http://fabrice.bellard.free.fr/qemu/
this: http://sourceware.org/gdb/
and this: http://sourceware.org/insight/

It all works nicely together and I can step through my code while viewing the C code and ASM. It's also got a memory viewer, so you can see if things are being written to memory correctly.

All you need to do is run qemu with -S -s in the command line, then connect with insight via remote debugging.

Cool! I use qemu too. Now I can use something similar to the MC++ debugger for my OS (in the MC++ debugger you can stop your code at any point)..

A cool feature with MC++ is when you're using managed C++ (which I try to steer away from since not everyone has .Net installed and your program takes 10 seconds to start and uses up 20MB of memory for no apparent reason) you can pause your code at any time, make some changes, then click continue (and wait a few seconds for their just-in-time compiler to do its thing).