[SOLVED] Page Fault when calling a virtual function

[IanSeyler]

You're using Pure64... what version? Also, have you verified that the entire kernel was loaded into memory. The current version of Pure64 only supports a 26KiB payload.

[RowDaBoat]

Thank you for your response, I'm using Pure64 v0.5.0. I got it from here http://www.returninfinity.com/pure64.html
I completely missed the 26KiB restriction, where is it documented?
My kernel binary is currently 28KiB, at this point I should either change the bootloader or write my own hd driver to load the rest of my kernel right?

[IanSeyler]

No worries. v0.5.0 should be OK in that regard as it loads the kernel from the file system after the switch to 64-bit mode.

I dropped the disk driver and file system support from newer versions of Pure64 to get the size down.

[RowDaBoat]

Awesome! I'll stick to version 0.5.0 then.
I'll try to verify the integrity of my kernel and if it was completely loaded as you guys suggested, then I guess I'll be back when I find something.
BTW, IanSeyler I love Pure64, thank you.

[RowDaBoat]

After a while the same error reappeared, this time I discovered that it happens when the amount of bytes used in string constants is above some limit. That made me realize that there was still something wrong in the linker script, probably in the .rodata section. After searching the net for a while I found this link: http://geezer.osdevbrasil.net/osd/cpp/index.htm

Which reveals quite a few things when linking a C++ Kernel:

• *(.text), *(.data), *(.rodata) and *(.bss) input sections should be declared with a wildcard at the end *(.sectionName*), since GCC may just use those names as a prefix for the actual section names.
• *(rodata*) input sections should be insde the .text output section
• *(.gnu.linkonce.t.*) and *(.gnu.linkonce.r.*) should also be included .text output section
• *(.gnu.linkonce.d.*) should be included in .data output section
• *(.gnu.linkonce.b.*) should be included in .bss output section

This is my current linker script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(loader)
SECTIONS
{
	.text 0x100000 :
	{
		*(.text*)
		*(.gnu.linkonce.t.*)
		*(.rodata*)
		*(.gnu.linkonce.r.*)
		start_ctors = .;
		*(SORT(.ctor*))
		end_ctors = .;
		start_dtors = .;
		*(SORT(.dtor*))
		end_dtors = .;
		. = ALIGN(4096);
	}
	data = .;
	.data :
	{
		*(.data*)
		*(.gnu.linkonce.d.*)
		. = ALIGN(4096);
	}
	bss = .;
	.bss :
	{
		*(.bss*)
		*(.gnu.linkonce.b.*)
		*(COMMON)
		. = ALIGN(4096);
	}
   endOfKernel = .;
}

This now works fine on my setup:
Language: C++
Compiler: gcc
Target: x86-64
Compiler Version: 4.8.2
Binutils Version: 2.24
Bootloader: Pure64
Binary Format: raw binary

I'm marking this post as SOLVED. Also I'd like to contribute to OSDev by documenting my findings on the wiki, should I create a new article or modify an existing one?

[no92]

You may want to add the link to the C++ wiki page and the description as well as the solution to the problem to the Linker Scripts page. If you can't edit the wiki yet, you'll have to join the wiki group on the forums first. After that, you'll be able to log in at the wiki front page.

[RowDaBoat]

Done! I added everything to the C++ article in a new "Solving .rodata Related Issues (GCC Only)" section, since the linker script changes are actually really gcc/cpp specific.

[RowDaBoat]

Here we go again: my rodata section got corrupted again (mostly strings) after adding adding some more code.
After a day of debugging and cheking the compiler's output with objdump -x, I found something that called my attention:
Although I am compiling all my source code with -fno-exceptions, most of my object files had an .eh_frame section.
Which according to this question on StackOverflow, may be used for stuff other than supporting stack unwinding.
My linker file was missing that section which is probably what was causing the errors, after compiling with the -fno-asynchronous-unwind-tables the problem seems to be solved again (I guess adding an .eh_frame section in my LD script should work too).

At this point, after all the times this bug has been coming and going away, I don't know if I'm just being lucky "solving" it, or if I am actually making progress, I don't want to generate false content; should this be added to the wiki too?

[KemyLand]

At this point, after all the times this bug has been coming and going away, I don't know if I'm just being lucky "solving" it, or if I am actually making progress, I don't want to generate false content; should this be added to the wiki too?

This is a pretty common situation in both OSDev (I've seen like three of this "reappearing bugs" today on the forum ) and general programming as well.

It's a good idea to remove what you wrote on the wiki, until the problem is finally resolved (BTW, there's no way to definitely know this, just guessing ). The OSDev wiki has been written by people that came before you/me, even before chase (the one that began this stuff on 2004 and OSDev.org's supreme god ). We don't want to troll those that will come after us .

Bugs that "reappear" are bugs that had never gone. What happens is simple: the solution is a dirty workaround, but not a solution. I'm not pretty sure what can cause this. Maybe the bootloader (Pure64)? Maybe your own code? We don't know! This bug is a pretty smelly one, and it smells everywhere. What's really happening on here ?

[RowDaBoat]

Indeed it is happening again, and I'm removing the section from the wiki.
I think I'll start working tomorrow on finding the minimum code required to reproduce the bug.