OSDev.org

matt11235 wrote:

Luca1 wrote:Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

imo this is one of the nicest places on the internet.

You just walked in, threw your code on the table and asked other people to fix it and then got upset when nobody spoon fed you more code. There's nothing wrong with asking for help, but you need to put some effort in yourself.

Luca1 wrote:

XenOS wrote:I doubt that QEMU crashes because you forgot to read the keyboard's status and data.

Well then give me another reason why my code works afterwards.

XenOS wrote:

Luca1 wrote:

XenOS wrote:I doubt that QEMU crashes because you forgot to read the keyboard's status and data.

Well then give me another reason why my code works afterwards.

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.

        unsigned char status = inb(0x64);
	if (status & 0x01) {
		inb(0x60);
       }

Luca1 wrote:Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

iansjack wrote:

Luca1 wrote:Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

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.

XenOS wrote: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.

while(1){asm("hlt");}

OUTPUT_FORMAT(elf32-i386)
ENTRY(start)
SECTIONS
 {
   . = 0x100000;
   .text : { *(.text) }
   .data : { *(.data) }
   .bss  : { *(.bss)  }
 }

nasm -f elf32 kernel.asm -o kasm.o
gcc -fno-stack-protector -m32 -g -c kernel.c -o kc.o
ld -m elf_i386 -T link.ld -o kernel kasm.o kc.o

Luca1 wrote:

iansjack wrote: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.

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.

dozniak wrote:

Luca1 wrote:

iansjack wrote: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.

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.

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

Luca1 wrote:I am not sure if I want/need friends in here.

iansjack wrote:That's, fairly obviously, the cause of your problem.

Luca1 wrote: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.

Luca1 wrote:That

Luca1 wrote:I am not sure if I want/need friends in here.

was meant as "I am not sure if I will continue in OS dev", because if someone is saying

iansjack wrote:That's, fairly obviously, the cause of your problem.

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.

Do you know the state of the stack? Do you know how the stack go into that state? (That's, fairly obviously, the cause of your problem.) Is your stack even valid?

FusT wrote:

Luca1 wrote: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.