OSDev.org

So this is another stupid query from me :3 don't be angry and as I am a noob here, please explain me the things in an easy way :p

I have been re-implementing the Paging and Memory allocation systems for my hobby OS (used James M's **** paging before :3)
But there is a need for me now. For some reasons related, I want to deliberately try writing to random memory locations (not random :3) ,after paging all the memory which I gonna use, to check wether it causes a page fault or not. I actually just want to map the whole usable memory by testing for page faults by writing and reading after allocating a page to where I am testing. If there is some or the other problem like read only page, protection violation, etc. because of which I just cant use the memory at that moment, It would naturally raise a Page Fault. Now Page Fault is not a problem here, its actually what I want. I want that when a page fault comes, it puts the value of a global var to say 1. I want then that the page fault function returns to the NEXT instruction after the write operation which caused the problem which would check wether the global var is 1 or not. If its 1, the function should put the global var to 0 back and set the memory location in memory map as not available or if not the case then put the memory location as available.

Now everything works fine except the RETURN FROM PAGE FAULT thing. It returns back to the instruction which caused it . But how to make it proceed to the instruction next? Because otherwise its not fruitful. And also, I don't want to temporary page fault handler I use here to allocate pages for the memory location because if the frame I am referring to already has a read only page or the memory location is simply not available, I would get in trouble. So please help me here. I am other alternatives, But I currently want to do it this way due to reasons :/
If someone can help me, I would get a precise mem map of any memory region. I don't want the mem map from grub itself :3 Please help me in making the Page Fault handler go to next instruction :p
EDIT: THE METHOD FOR MAPPING I USED ABOVE IS REALLY A BAD IDEA. NOT USING IT. BUT STILL I WANT TO KNOW HOW TO RESUME WORK AFTER A PAGE FAULT, FROM THE NEXT LINE OF CODE??
NOTE: I am bad at assembly, Programming in C.

That is not how page faults work at all.

:/ I was asking a question :/ but according to what I know, Page fault is called when I try to write to a location which has not been paged or which has been paged as read only etc. That's only what I have learnt and read :/ its a interrupt basically? I register my page fault handler to interrupt 14 and it works even :/ but still, I would be glad if you correct my concepts :p

MANUALLY PROBING FOR MEMORY CAN DAMAGE YOUR COMPUTER.

If you don't want to use the memory map from GRUB, you can ask the BIOS directly. You have to be in real mode to do that, so it's much better to let your bootloader (GRUB) deal with the BIOS.

ya I know that. if I do this in physical mem, virtualbox automatically shuts down the system. But I am probing in virtual memory after enabling paging. I guess anything illegal would through a page fault, right? if I am wrong, I still need a way of moving to next inst. after a page fault, for other purposes

No. You set up the page tables, so you determine what goes to what physical memory. There is no magic filtering involved by the mere enabling of paging.

To be honest, I don't believe you do once you know how things really work.

Hi,



Why?

There are only 3 reasons I can think of:

• C style "signals" (SIGSEGV)
• A messy extension to a language's run-time exceptions (e.g. C++ exceptions; like "try { ... } catch (pageFault) { ... }")
• Unit testing your kernel to make sure it got page permissions correct

Of these, the first 2 need a more general approach (e.g. starting with some sort of "send signal/exception to user space" that can be used for many different things, and code in standard library/ies to support however the kernel implemented it).

The third reason (unit testing) is a special case, not something you'd leave in the OS forever.


Cheers,

Brendan

Thanks Brenden and Combuster. Yeah its the reason 3 :p I am just experimenting. And Combuster, sorry I got confused with that stuff, because u see I tend to do more experimenting before reading much :p that's why I call myself stupid. But I came to that conclusion just because when I was in physical memory, in virtualbox, when I accessed something illegal, the virtualbox just restarted. But when I tried to FIRST make some pages for that location and THEN enable paging (as the JamesM paging, I used earlier, does for first few used memory spaces), and then try to access the same location which crashed the virtual box, it gives me a page fault only but it does not crashes or anything like that. Things I put in the page fault function run uninterrupted.
And I still want to know how to make the page fault handler return and resume work from the NEXT line of code :/

And thanks for reminding, I want something like the try and catch in c++ and c# in c if its possible (anything, anyway) or shall I do this stuff in c++ itself?

Okay I got it, Its definetly not a good and smart way to map memory. Sorry for this, I am not gonna use this method, gonna use the grub.

But still I want to know how to resume work after a page fault

Hi,



In that case; cheat.

You can put the "address page fault handler should return to" in a register, and then have a special/temporary page fault handler that replaces it's "return EIP" (on the stack) with that register. That way you can do something like:





If you must; I'd only support signals (e.g. SIGSEGV) in the kernel. If a C++ compiler/library wants to support "CPU exceptions as language exceptions" (which isn't standard for C++) then it can implement it on top of the SIGSEGV signal handler.


Cheers,

Brendan

You could also read the EIP instruction stream and determine what next EIP should be and set it manually

This sounds like you want exception handlers, something along the lines of:


If I understand this behavior correctly, this essentially "registers" the "catch" "function" with the application's context in the OS, so that if the OS catches an exception, it can look up the currently registered exception handler routine and jump to it. Normally, these can be nested, so in that case, it would be a stack of handlers, not just one handler. The OS would just jump to the top of the handler on the top of the stack.

Someone may be able to go into more detail, since I've never implemented one of these, myself.

Also, this may be overkill for what you are looking for, but it's basically a more elaborate version of Brendan's suggestion.