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.
Hi everyone,
Now my OS can load 32-bit binary files ".bin" that compiled by NASM but my OS not multitasking.
I have searched in wiki about something that can guide me to handle the errors in a running program when they happen but i didn't find anything.
my OS works in ring 3 (user mode) so that i can't use "hlt"
so that say that a developer added "hlt" to a binary program and loaded it in my OS , the OS will generate #GPF when reaching to the "hlt" so that i want to handle the errors that occurs in the loaded bin program without casing the OS to stop and case #GPF.
i tried to use "return" and "iretd" in the #GPF error handler to allow me return again to my OS and terminate the program but it didn't work and the CPU generated another error instead of the #GPF.
Can anyone help me by guiding me to a proper way to handle the program errors?
---------------------------------------
Thanks in advance
Last edited by melgmry0101b on Sat Aug 13, 2011 6:52 am, edited 1 time in total.
If you iret from a GPF or any trap handler you will be returning to the ring 3 program.
Sometimes that is what you should do. For example perhaps you could emulate the 'hlt' instruction by sleeping or running another thread and then afterwards you would return to ring 3. Note that for a 'fault' class exception the processor will try to re-execute the same instruction so the fault will repeat. You need to modify the IP to point to the next instruction so the programme can continue. This type of handling usually applies to page-faults and the like, where faults are expected and the kernel knows exactly how to fix them. For a page-fault of course you don't modify the EIP and the faulting instruction will repeat and presumably succeed.
If on the other hand you decide to kill the process, don't IRET. Assuming the trap handler is in ring 0, simply delete the process entirely, perhaps inform its parent process or the user that it has been killed (usually OS designers try to use an obscure message so the user never really knows what happened !!) and find something else to do.
If a trainstation is where trains stop, what is a workstation ?
gerryg400 wrote:simply delete the process entirely, perhaps inform its parent process or the user that it has been killed (usually OS designers try to use an obscure message so the user never really knows what happened !!) and find something else to do.
Thank you very much for you reply
but I have killed the process of the program but the CPU generated another error , it didn't ignore the previous generated error from the killed process, How to make the CPU ignore generating errors?
Now any program that runs in my OS should use "ret" at the end of it , if it didn't have that , the OS will case #GPF , i want to ignore that #GPF and kill the process then return to the OS to continue working , and if the program executed "hlt" the OS will also generate #GPF and i also want to ignore it.
Mozo40 wrote:Now any program that runs in my OS should use "ret" at the end of it , if it didn't have that , the OS will case #GPF , i want to ignore that #GPF and kill the process then return to the OS to continue working ,
You need to find a way to detect this situation. But you shouldn't think about 'returning to the O/S'. When you enter your fault-handler you are already in your O/S. There is no need to return. Just fix up your stack and the rest of your kernel environment and away you go.
Mozo40 wrote:and if the program executed "hlt" the OS will also generate #GPF and i also want to ignore it.
You fault handler should look at the instruction that faulted. If the opcode is 0xf4, then increase by 1 the EIP that was pushed onto the stack, then iret back to the application. It should then continue from the instruction after the hlt.
If a trainstation is where trains stop, what is a workstation ?
Mozo40 wrote:and if the program executed "hlt" the OS will also generate #GPF and i also want to ignore it.
You fault handler should look at the instruction that faulted. If the opcode is 0xf4, then increase by 1 the EIP that was pushed onto the stack, then iret back to the application. It should then continue from the instruction after the hlt.
