OSDev.org

I don't want copy and paste code - but someone telling me that I forgot to read the data it would've been more helpful than what I got.

You are the one who made a claim which doesn't make sense at all, so you are the one from whom to request a proof, not the other way round. If you want to know what was really going wrong, then show all your code, explain every line in it and start understanding it. Right now all you're doing is guesswork, which is impossible to reconstruct.

You have the full code in my original post, which lead to qemu crashing with the error shown in the original post. After adding



to my cihandle function it worked.

One day, should you persist with OS development, you will realise how good the advice to learn debugging was.

Whatever, you say you don't need friends here, and that's fine by me. People do tend to react badly to those who are rude to the unpaid volunteers here who try to help them.

First of all, you have not shown any linker script or specified where the kernel is loaded, or given any compiler / linker command line. Without this information we can only guess what your code does.

Second, the change you introduced does not fix the problem, at best it hides it, or is even completely unrelated. Your code enables interrupts at some point by executing "sti". Once your kmain function is done, it returns and you execute "hlt", with interrupts enabled. As soon as an interrupt occurs, the interrupt handler is executed, and returns. After that, the instruction after hlt is executed, which happens to be your inb function. It ends with a "ret", but since there was no "call" to return from, it jumps to whatever happens to be on the stack right now, obviously some bogus address, and continues running from there, until it leads to a crash (like the one QEMU reports - execution runs somewhere where there is no usable RAM). Now your change may have caused something to run differently, so it doesn't jump to the same bogus address, but it still jumps to a different one, it just doesn't crash immediately (but it will at some point).

The best way to actually figure out what's going wrong is to single-step your code in a debugger, so you could use QEMU + GDB for that, or use Bochs instead, which has its own debugger and also tells you much more about what happens in your code.

I am not saying that a debugger is not a good advice.
The problem is that the help that was provided to me was not help at all.



This is the first thing that actually helped - thanks!

I added to the end of kmain let's hope it stays bug free.

if you are still interested:

link.ld

and the commands used to compile:

That's fine, we don't need you too.

That was meant as "I am not sure if I will continue in OS dev", because if someone is saying it means that they know what the problem is without telling me why it occurs or how it is fixed. Which is, in my opinion, not nice.

First off, it's perfectly fine to have that opinion.
Having said that, the goal is to help people out by giving them a push in the right direction, not give them the answer to solve their problem. This is because you should completely understand why your code doesn't do what you expect it to do instead of relying on others to fix it for you. If you don't completely understand why something is/isn't working you'll never be able to fix future (and more complicated) problems by yourself.

I do realize this approach may seem hostile towards newcomers but it scares of copy/pasters not willing to learn.

Now, do you think it fair to quote a single sentence out of context? The fuller quote is:I told you exactly what I thought the cause of your problem was (a corrupted stack) and, in the same post I told you exactly how to solve it. (Use a debugger to find out where and why the stack is being corrupted.) You seem to be expecting someone to debug your program for you and then tell you exactly where the incorrect instruction in your program is without putting in any effort yourself. That's not the way it works.

In my opinion it is not nice to be rude to people trying to help you and it is not nice to twist their words - and lie about what they told you - by quoting out of context.

I think your inability to accept advice, and your willingness to give up so easily without putting in a little groundwork, are not going to stand you in good stead with what is a fairly difficult field of study. I think you are right to doubt whether you will continue with OS development.

This is probably not going to help this situation at all, but why don't you just leave this post, to preserve the kindness / niceness of these forums?

If that was addressed at me, I'm more than happy to leave.

It just looks like you are trying to keep the knowledge to yourself if you are not giving answers to the problem. This is the first forum that I'm in where it is handled this way.