GCC's evil obscure black magic

[solano]

I'm getting started to OSDev'ing, so I read some articles on the wiki and followed the Barebones for C. So I wrote a function to print a character:

Code: Select all

uint16_t _attrib = 0x09;

void kwrite_char(char ch, uint16_t offset)
{
	volatile uint16_t *where;
	where = (uint16_t*)(0xB8000 + offset*2);
	*where = ch | (_attrib << 8);
}

Everything ok, it prints anything I want, so I also wrote a function to print strings:

Code: Select all

void kwrite_string(char* st, uint16_t offset) //newlines wont work
{
	while((*st)!=0) {
		kwrite_char((*st), offset++);
		st++;
	}
}

So I used it. Now if I use this function, everything I printed gets blank, even if i printed it with the first function, before or after this. So:

Code: Select all

	kwrite_char('H',81);
	kwrite_char('e',82);
	kwrite_char('l',83);
	//kwrite_string("This is an OS. Or not", 320);
	kwrite_char('l',84);
	kwrite_char('o',85);

When I leave that as a comment, I see a normal purple 'Hello' on my screen. If I uncomment it, I see black (background color) space where it should be the two messages, whether before ('Hel') or after it ('lo'), or even itself ('This is an OS. Or not').

I'm not sure if I was clear (sorry for the bad English, I'm brazilian), but that scares me.

[Jezze]

I think you are missing the .rodata section in your linker script?

EDIT: I had to look it up. DOH!

[solano]

Unfortunately no.

[Kazinsal]

What happens if you were to make the attribute value a constant (numerical or through #define)? Does that change anything? What about changing it from a uint16_t to uint8_t?

[solano]

Making it const solves the problem. Still don't know why, but thanks

[Combuster]

I don't like the idea of magic fixes, and I'll stick with Jesse for posting the most likely answer so far - things breaking over string constant use is a typical case of broken linker scripts causing certain objects to disappear.

And since you already use bochs, switching to the debugger version is easy. You can check if and where the string is in memory. Doing the same thing by dumping the linked binary and finding the string's address should of course yield the same values.

[Kazinsal]

I don't like the idea of magic fixes

Neither do I, but I was hoping that my suggestions would inspire solano to think out what the components of the functions are and what could possibly cause the issue, thereby finding a better and correct solution.

However, as you and Jezze stated, there's probably also broken linker script involved. However I'd also test whether or not it was the uint16_t being a uint16_t being a problem. You know GCC and it's evil obscure black magic

[solano]

Neither do I.

I wrote "still don't know why" because I checked all those things (no problem on being uint16_t, no problem with linker script, nothing changing _attrib in the code, it really happens only if I call the function kwrite_string) and I don't understand the problem yet. I'm trying bochs debugger, but it's not helping. I hope I'll fall in one of those eureka moments.

Sorry for the mistake.

(and again for my English, of course)

EDIT: After some debugging in ddd I found out _attrib is set to 00 initially, only if I call kwrite_string. When I don't, it's normally set to 0x09. And since that function is defined (and called) much later, (and I also identified that in kernel.o, so it's not a linker problem) this is *really* a GCC's weird evil obscure black magic.

I'm now using #define instead of const to solve the problem, since _attrib is just a way to make it easy to change the main color. Thank you for the help.

[qw]

Since "_attrib" has external linkage, I guess there is another "_attrib" somewhere in your source code.