kprint won't dereference strings properly

[falstart]

I just finished making a bootloader that loads up a simple kernel with a kprint function. However, the kprint function doesn't print the string I feed to it in any predictable manner. Sometimes it prints the same thing no matter what I load and sometimes it prints different things. It tries printing a random collection of symbols and characters.

I've tested everything else, including passing ascii integer pointers to a function and those work fine. The problem seems to be with the char*. Any help would be greatly appreciated because this is going to make me explode.

Code: Select all

//Simplified into kmain for clear testing
void kmain()
{
	char* str = "test";
	unsigned char* vmem = (unsigned char*)0xb8000;
	int i=0;
	while(i < 8)
	{
		vmem[i] = *str;
		vmem[i+1] = 0x07;
		str++;
		i+=2;
	}
}

I find it hard to believe that the problem is in the C since it's so simple, but everything else works. Thanks.
Link to the very simple bootloader, just in case the problem is in there: http://codepad.org/uq7fHlvm
And the start.asm is the one on the wiki nearly verbatim: http://codepad.org/x0rtZnsm

[gerryg400]

This exact question is asked frequently. Search the archives and you will find the answer.

I can't remember the answer but it was definitely in the last 2 months.

[falstart]

Thanks for the advice; I've just finished searching and reading the forum. Most of the posts have problems with the .rodata section, though. I'm using the linker from the Bare Bones tutorial exactly and it does include a section for .rodata. When I use objdump I can see the .rodata section (it says start address: 0x00, is that a problem?) with 74, 65, 73, and 74: "test". Using readelf -x .rodata I get the same thing.

[gerryg400]

The best approach is to build your binary exactly as it will be deployed. Then run it through a debugger (like bochs) or disassemble it with objdump. With very close inspection you will spot the problem.

There was something wrong with the string pointer for one guy, it was off by 4 bytes, but I can't remember why.

I guess you're on windows. Do you use gas/gcc/ld ? Making an ELF file ?

[falstart]

Yeah I'm making an ELF file. I'm on linux though so I'm using nasm. Right now I'm running it through bochs and gdb so with any luck I'll find the error. Thanks for the tip.

Edit: Turns out that I was missing the OUTPUT_FORMAT("binary") in the linker meaning you were right about building the kernel with the final output. Google is good. It's somewhat humorous since a few times I did wonder if I could even execute an ELF.