I'm following the tutorial "Bran's Kernel Development tutorial" and I'm stuck. When I want to print a string on screen, GRUB gives an error. putch('A'); works perfect (prints the caracter), but puts("Hello World"); gives:

Even before my OS has started! And when I press any key I see the menu of GRUB again...

I'm using the following code:


Please, somebody help me

What happens if you just try to do puts() with a single character? Does that work the same way as putch()?

Well, my posted puts has a bug (it doesn't use the length of the string). But that's not the problem, strlen doesn't even work!

So putch(strlen("Hello") + 'A'); should print 'F'. But thát doesn't work.

This works:


This doesn't work (but the tutorial says that this should work):

It seems that things with a loop in don't sit well. You may find that your compiler is trying to optimise out the loop as much as possible and this might not use legal code/syntax.

Check your compilers documentation about branching loops etc and see what it says, alternatively tell it to compile with no optimisations.

Yes, you're right. When I use the following code (no loops) it works correct:


But when I compile (using gcc) the original code (with the loop and the pointer inside the loop) using -O0 (that's a capital O and a zero) I still get the weird error.

Hmm. When I use puts("Hello World"), my kernel grows to 1 meg. So maybe C is correct... The fault might be this.

But I still don't know how to fix it.

start.asm


link.ld


Have I done something wrong?

EDIT: Solved! I had to use nasm -f elf -o ... in stead of nasm -f aout -o ...

Just an autopsy on what was happening here (and why):

Chars are just the same as numbers, in the end - just a different way of representing it. So, they don't need any special allocation in the resulting image after linking.

But, a string needs to be stored elsewhere - when you type puts("Blah blah, some string"), that string is allocated in a separate part of the image, since the call to puts is actually just passing a pointer to that string. (if there's a pointer, it has to point somewhere!)

So, introducing the first string in the program was causing nasm to create a new section of this kind of pre-initialised data, which maybe started at the 1MB mark in a COFF file. Who knows.

One of the problems with Brians tutorials is the linker script, use the one bellow it has a rodata section that will help to prevent errors in future.

I have a problem that is similar to this one.

I am following Bran's tutorial, and I was having some weird errors while using char* pointers.
I checked everything, realised strlen wasnt working, etc. Added a .rodata section to my linker file.

And then the problem seem to appear everytime I use a loop, or a pointer, or both.

Ex. : I write
strlen(myPtr);
and *myPtr is always == '\0', so strlen always return 0.

Ex.2 : The code below only works until "HERE". After, string is equal to zero. Always.
( value displays HEX value of the char: value('R') = 0x52 )

Did everyone figure out their problems? Was it really the linker script? If so we can update that, but Bran tested everything, so maybe something changed with gcc or ld?