OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Feb 17, 2020 7:29 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Translating CPU exceptions into C++ exceptions
PostPosted: Tue Jan 13, 2015 4:59 pm 
Offline

Joined: Tue Jan 13, 2015 4:55 pm
Posts: 3
Hi all!

Im new to this forum, and didn’t really know where to post this, but felt like this was the best forum:

I currently have c++ exceptions working in my OS, but would now like to extend them so that I can “throw back” CPU exceptions into the code that caused the fault, for example:

Code:
int result = x / 0;

Should be able to throw DivideByZeroException.

Code:
int value = *nullptr;

Should throw a NullReferenceException

My assumptions are that I can “forward” the control flow after an exception interrupt, to a function that would throw the relevant exception. From my understanding, this is what the .net framework does for generating NullReferenceExceptions (by intercepting GP faults)?

Before I start toying around with this idea any further, are there any examples of people doing something similar, or is my method simply not possible?

Any help is appreciated!


Top
 Profile  
 
 Post subject: Re: Translating CPU exceptions into C++ exceptions
PostPosted: Tue Jan 13, 2015 5:36 pm 
Offline

Joined: Fri Jan 09, 2015 7:11 am
Posts: 1
i have seen this so many times, and am not exempt myslef

Somebody starts trying to do ex-handlers for like div by zero or issues which I {eventually} find in printf or whatever — pointers in 16-bit or even some of that masked-off running in code where we are told flat 32-bit address space exists ▬ maybe it does but going in with dot net to do ex-handling in ring-0 is not a good idea of a place to start unless you want to be like me ← collecting book after book / after year → assembly-level systems programming is so far from where dot net targets as their customer that your best approach is to read whatever compiler you are using on how to write ex-handlers then do it that way

One very famous comment in headers for Java has very accomplished person speaking of the implausibility of writing cross-platform where one masks part of the pointer then another does not and doing it all with defines ---- try digital mars:

D Programming Language


Top
 Profile  
 
 Post subject: Re: Translating CPU exceptions into C++ exceptions
PostPosted: Tue Jan 13, 2015 6:32 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

wraund wrote:
My assumptions are that I can “forward” the control flow after an exception interrupt, to a function that would throw the relevant exception. From my understanding, this is what the .net framework does for generating NullReferenceExceptions (by intercepting GP faults)?


I'd assume that the kernel would only provide support for signals; and the C++ run-time would have signal handlers that "throw".

However, if you look at "std::exception" you'll see that there are no standard exceptions that correspond to things like illegal opcode, page fault, general protection fault, etc (or SIGILL, SIGSEGV, etc). Based on this, I'd assume that the CPU's exceptions typically aren't tied to the language's exception handling system (e.g. and if there's a page fault or something the process crashes); and that you'd be adding a non-standard extension to standard exception handling in C++, in the hope of making the language slightly less bad.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Translating CPU exceptions into C++ exceptions
PostPosted: Tue Jan 13, 2015 8:24 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 21, 2011 9:47 pm
Posts: 286
Location: Tustin, CA USA
wraund wrote:
My assumptions are that I can “forward” the control flow after an exception interrupt, to a function that would throw the relevant exception. From my understanding, this is what the .net framework does for generating NullReferenceExceptions (by intercepting GP faults)?


I have considered this myself and toyed with several thoughts, though I have not implemented any since it is still too early in my development yet. Please consider it all just theory. I'm also sure someone can quickly turn it into Swiss cheese.

One method I am currently considering is to have a callback function registered in the process structure and if any hardware exceptions (in particular INT 0, 4, & 5 to start) occur to execute the call-back function. At this point, it makes more sense to twiddle the stack to return to this address (replacing the exception address) rather than calling the function while still at ring-0. It would also be an optional callback and would be handled by the language runtime.

Brendan wrote:
I'd assume that the kernel would only provide support for signals; and the C++ run-time would have signal handlers that "throw".


With Brendan's reply about sending a signal, I would consider this recent debate which involved sending signals to crashed programs.

_________________
Adam

The name is fitting: Century Hobby OS -- At this rate, it's gonna take me that long!
Read about my mistakes and missteps with this iteration: Journal

"Sometimes things just don't make sense until you figure them out." -- Phil Stahlheber


Top
 Profile  
 
 Post subject: Re: Translating CPU exceptions into C++ exceptions
PostPosted: Wed Jan 14, 2015 4:35 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 278
Location: Private, UK
I am quite surprised to see Brandan recommending use of signals in this case, but anyway...

The problem with using 'throw' in a signal handler is that it's outside of the C++ standard and you have to be very careful with the stack. The November 2014 draft C++ standard even says "In particular, a signal handler using exception handling is very likely to have problems." in a footnote.

According to the C99 standard:
Quote:
If the signal occurs other than as the result of calling the abort or raise function, the behaviour is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler.


And the C++ (Nov 2014 draft) standard:
Quote:
The behavior of any function other than a POF used as a signal handler in a C++ program is implementation-defined.


If the "signal" has been created by "raise" in the same thread, your signal handler is probably running like a "normal" function call, so all should be fine. If, however, it's been called by the kernel, you need to make sure that the stack is in a state that the C++ runtime understands. If you're using an unconventional method to emulate POSIX-style signals (e.g. running them on a different thread, which is perfectly OK according to 1.10.2 in the Nov 2014 C++ draft), then making it work is going to be difficult if not impossible.

Of course, for your own kernel, you can define the way that signals work in a way that's compatible with the C++ runtime's exception mechanism. At the very least, you'll need to make sure you "unmask" the signal before you use 'throw', or you'll never receive that signal again.

_________________
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], MSN [Bot] and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group