Debugging during OS' development

[CodeVisio]

Hi All,

A question that came into my mind, as user mode developer, is how one can debug an OS while developing it?
You cannot print a message into the monitor since you couldn't have written video code, or you cannot print a message into a file since you
couldn't have done file system code and so on.
How is debugging done in those cases? Do you have a preferred way?

Thank you

[rdos]

The typical way today is to use an emulator, but there are other ways (especially for problems that only appears on real hardware).

1. The easiest is if you have a functional video and keyboard. Then you can make an interactive (kernel-mode) "app" that lets you display threads, state (registers) and memory, and possibly single-step.

2. If you have a functional TCP/IP stack, you could do more or less the same, but with a "stub" that allows keyboard / video input/output to be generated remote, and sent to the target system. In this case you need a functional TCP/IP and Ethernet driver, but no video or keyboard. Alternatively, the same thing can be implemented on a serial or parellel port.

[pcmattman]

During 'initial' development, a serial port is usually the way to go. It's dead simple to write data to a serial port on a PC, and it works on emulators and real PCs alike.

[Combuster]

Serial is in most respects the best solution possible, that is, if you have the equipment. Logging to the screen is for many people the more appropriate solution because you hardly need anything resembling a driver to dump text on the VGA console - it's the first thing you typically do when writing your first bootloader or kernel.

[iansjack]

I'm not quite sure what you mean by "user mode developer"; you don't write OSs in user mode in general.

If you mean debugging a kernel, I just dump an error code to the screen in the early stages. It can be as simple as printing just one character. The code to do that, at least on a PC, is trivial. And it's probably best to halt the processor at that point as multiple errors will overwrite each other. Later on you can write a simple kprintf() routine and provide more comprehensive error messages. And if all that doesn't work I single-step the assembly code in an emulator.

Or do you mean debugging user-mode programs on your OS? I wouldn't be writing user-mode programs until I had at least rudimentary system calls to handle keyboard and console, so the problem doesn't arise. Printing to the screen is one of the first elements of even the most elementary OS tutorials.

[CodeVisio]

Sorry, English is not my native language, so I'm not accustomed with all syntax/semantics of it.

with

A question that came into my mind, as user mode developer, is how one can debug an OS while developing it?

I meant and in other words: I have many years of exp. building desktop programs and as such that I usually use many tricks, standard ones and not, to show debug information while building programs in user mode environment, prevalently under Windows.
In these days I'm trying to follow tutorials about building a kernel/OS and one of the first things that came into my mind, as desktop developer, was, "If I haven't coded video stuff or network stuff or file sytem stuff or message beep stuff yet, in other words I'm at the first stage of building an OS, how can I output any debug information if, for example, something is going bad?"
Just that.

thank all of you.

[DavidCooper]

If you're just starting out, you want to experiment with sending information to the screen. It's easy to do if your OS is to run on a standard PC which starts up using a text screen mode as you can simply send ASCII to every second byte of screen memory and colour values for them to the bytes in between. That lets you see if a piece of code has run or not, and you can also use it to indicate the results, perhaps writing more complex routines to call on which read bytes of memory and print the values they contain to the screen in hex (perhaps to an x,y location on the screen, and you can add some code to this to wait until a key is pressed before the next bit of code is run) - you can just build your own tools as you go along based on what you need at the time and increase their capability over time. Once you've built a simple operating system for one kind of machine, you can then transfer what you've learned from it to building one for a different kind of machine with a different processor, knowing that your algorithms already work and that it's primarily a matter of translating existing code.