OSDev.org

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:
Should be able to throw DivideByZeroException.
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!

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

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

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.

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:

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:

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.