OSDev.org

My OS crashes on real hardware for now, but it worked fine a week ago. So, the question is: How to debug my operating system on real hardware and fix my error?

Hard but powerful way:
1. Debug it using Bochs.
2. Implement GDB stub and debug via serial port.

Easy way: don't forget about printf-debugging. Insert printing calls around suspicious parts of code, then look where your execution has stopped.

catnikita255 wrote:How to debug my operating system on real hardware and fix my error?

You can print debug information on screen or use RS232 or another port (it is harder). You also can use infinite loop (in the case of triggering a hardware reset).

Nable wrote:Hard but powerful way:
1. Debug it using Bochs.
2. Implement GDB stub and debug via serial port.

Easy way: don't forget about printf-debugging. Insert printing calls around suspicious parts of code, then look where your execution has stopped.

My OS works fine on Bochs. I can't debug by printfs, because it crashes before it can write comething on the screen. And about serial port - I don't have serial port on my notebook. I can do it with my development machine, but I don't have any serial cables.

I am stupid. Delete this thread, please, it was one line added by me I don't know for what - accessing memory on -1.

If you use a version-control system such as git, you can view the commit history and see what's been changed in the past week. Yet another reason why I've started using git as part of my regular workflow.

onlyonemac wrote:If you use a version-control system such as git, you can view the commit history and see what's been changed in the past week. Yet another reason why I've started using git as part of my regular workflow.

I cannot agree more. While it doesn't have to be git and Github (a lot of people dislike git, it seems, though I've never had much trouble with it), some sort of off-site version control is a must even as a hobbyist, especially in a major project like OS dev. There are enough different [CD]VCSes, and free, low-cost, or ad-supported [CD]VCS hosts, that there are very good few reasons why anyone wouldn't use one.

Schol-R-LEA wrote:

onlyonemac wrote:If you use a version-control system such as git, you can view the commit history and see what's been changed in the past week. Yet another reason why I've started using git as part of my regular workflow.

I cannot agree more. While it doesn't have to be git and Github (a lot of people dislike git, it seems, though I've never had much trouble with it), some sort of off-site version control is a must even as a hobbyist, especially in a major project like OS dev. There are enough different [CD]VCSes, and free, low-cost, or ad-supported [CD]VCS hosts, that there are very good few reasons why anyone wouldn't use one.

Note also the value of a VCS even if you don't link it to an online host. Personally I use github for some things, but a lot of the time I use git "offline" (i.e. just a local repository, with no source repository to push to) to manage my own code on my hard drive.

Testing on real hardware should be done ASAP because emulators are not real hardware. Debugging is best done by catching serious bugs like protection fault, stack fault and double faults with handlers, and then printing register state on-screen. These handlers can be tested on an emulator. Printf-debugging is worthless.

rdos wrote:Debugging is best done by (...) printing register state on-screen.

rdos wrote:Printf-debugging is worthless.

Yup, rdos is back in full glory!

onlyonemac wrote:If you use a version-control system such as git, you can view the commit history and see what's been changed in the past week. Yet another reason why I've started using git as part of my regular workflow.

And don't forget about bisect. Just let git tell which commit exactly caused the bug!

rdos wrote:Testing on real hardware should be done ASAP because emulators are not real hardware. Debugging is best done by catching serious bugs like protection fault, stack fault and double faults with handlers, and then printing register state on-screen. These handlers can be tested on an emulator. Printf-debugging is worthless.

Heh, especially when said printfs alter state, either preventing bugs or triggering them. I started out printing stuff to the screen, but later switched to Bochs's debug IO port. Even that can alter behavior significantly (blah).

Btw, in addition to printing out registers in exception handlers, it can also be helpful to print out the first dozen or so bytes from the top of the stack.

I must be misunderstanding printf debugging. What's wrong with it ?

gerryg400 wrote:I must be misunderstanding printf debugging. What's wrong with it ?

Everything. They alter state and introduce new bugs + cannot tell you what a debugger typically can tell you. Once the basic exception handlers are in place, the next step is to integrate a remote debugger or local debugger thread so you can single step the kernel, preferably in source-code form. Before that is done, planting "int 3" in code, which triggers the exception handlers, is a good way to get the current register state.

Of course, if you are in an emulator rather than on real hardware, then the emulator might have good options for doing the above an easier way, but you still need it when you come to real hardware that isn't booting.