Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
have you triggered a pagefault prior to calling this function? if not, there is likely to be nothing or garbage in cr2.
I read cr2 directly after a page fault to save off the address causing the exception. One never knows what ideas can spring into a processor's mind. ];->
btw, if my knowledge of at&t syntax isn't too weak, I daresay your function is correct. Mine looks aequivalent, just that it's written in intel syntax.
weird... i did another test and cr2 had a value... gotta look through the other test (it was from my malloc function), maybe it does something at address 0 (have no idea what) and otherwise it's just really weird. Thanks for the help.
try to access some not mapped in address, say 0xdeadbeef. - send your cpu to hell on purpose, so to say.
Have the kernel trap into the page fault handler and there, read the cr2 value. If it shows the address you have tried to access - voila, your function works perfectly
when i create via the normal routine (so not using a page fault, doesn't work yet) a pagetable, bind free space to it, create an integer with the virtual address of the page and fill it with a number it's always -1 ???. does anyone have a damn idea why this is happening, otherwise i'll post some code.
My first guess: are you printing or if()'ing test as a number? It's a char, and your printf function says -1. Which is correct, since 0xFF is -1 in 2-complement notation.
(right..? I'm sorta feeling a bit lost, but iirc it was.)
Now I'm somewhat confused to what error you're referring. You mean the -1? In that case, there is no error as far as I can see (afaics? ) but to be sure, write something else as 0xFF to 0xA0001004 and see what printf says.
About the CR2 which is sometimes 0, I'd think it's a dead pointer somewhere in your malloc(), and that your malloc runs in ring-0, causing eip to actually change to NULL, and crash since there is no code there, which in turn causes the pagefault.
I've just dumped test2 as hex, and that says 0xFFFFFFFF. I checked it again with an 'if'. How is it possible a char contains the value 0xFFFFFFFF??? It doesn't matter I give test2 the value 0x10, 0x35 or 0xFF, it also doesn't matter I define it as int, short or as char. When I make test2 unsigned, the hex value is 0xFFFF. I'm really confused now.
On the x86, char and short are scaled up to int anyway, it doesn't make any difference what type you use since GCC 32bit aligns it to speed up access.
If printf always writes -1 no matter what you change test to then you may have a problem. Try 0x7F, that should print 127 (The highest possible value of an signed byte). Also try send 0x7F to it directly and see what it prints in both cases, or you could just breakpoint the instruction and inspect the memory with Bochs.
In the Bochs debugger, type "x 0xA0001004", you can place a breakpoint using "pb linearaddress"(IIRC) or you can just place __asm__ ("hlt"); in your code then Ctrl+C in the console to show the debugger prompt.