OSDev.org

berkus wrote:Properly designed shared libraries allocate resources local to threads/processes that use them (or use no shared state at all). This solves the problem in its entirety.

berkus wrote:Depends on what you understand under "exceptions" - is that language exceptions, structured exceptions (like windows SEH) or something else?

berkus wrote:First of all, language level exceptions are different from access violation or division by zero - these are signals.
Second, the exception handling works by adding an exception handler into some sort of exception handling block that is referenced from stack (e.g. some function scope), which obviously works as you call into the shared library too.

1. When a process wants to raise an exception, it calls _Unwind_RaiseException with a pointer to an exception object to be thrown. I have forgotten exactly how these objetcs are allocated, though it must be noted that the exception handling framework includes a method for allocating space to store a certain number of exceptions as a last resort method if you can't get memory from the system allocator (E.G. this method is most likely used to raise std::bad_alloc when out of memory)
2. _Unwind_Throw looks at its return address to find the calling function
3. The object (Shared library or executable) which contains the function is looked up. The .eh_frame section of this shared library contains an ordered list of all the functions in the object for which exception handling is necessary. The table also contains a pointer to a personality routine. Each language defines a personality routine; you are probably familiar with __gxx_personality_v0 if you have done any work with G++.
4. The personality routine is invoked. The personality routine looks at some language specific data (How this is associated with the function is defined by the library ABI) and decides if it needs to handle the exception or if the unwinding should continue. If there is a handler, then the exception handling framework invokes it. The handler can then specify if it has finished handling the exception or wishes to continue processing it. If there isn't a handler, the unwinder follows some more instructions (in the .eh_frame section) to pop the frame and invoke any destructors in it
5. The frame has been popped. The IP of the next frame up is looked up. Jump back to step 3

• Records for locating the information for each function
• Information describing the frames contained within each function
• Instructions describing where to find certain information in a frame
• Instructions describing what native code helper functions to invoke

Owen wrote:The best way of thinking of them is just as blobs of code mapped into the calling process by the loader.

  /-L-\
 / RTL \
 |      |
 A      B
RTL    RTL

Owen wrote:When a process wants to raise an exception, it calls _Unwind_RaiseException

Artlav wrote:

Owen wrote:The best way of thinking of them is just as blobs of code mapped into the calling process by the loader.

Exactly what i have.

There are two problems, however - resource allocation and exception handling.

Let's take two processes, A and B and a library L.

Code: Select all

  /-L-\
 / RTL \
 |      |
 A      B
RTL    RTL

Each have their own language RTL and with it's ways of handling exceptions and getting resources, in particular, memory.

Case 1, memory allocation:
L allocates memory from the kernel for it's heap. Done by the language RTL of it (for whatever reason from straight malloc to object creation and dynamic arrays).
This happens when the L routine is called from A, for example.
The memory allocated is registered to A.
Now, A terminates.
Memory gets released and is later allocated to something else.
But L still consider it occupied, so when B gives a call chaos ensues.

Case2, exception handling:
Once again, we're in L by grace of A.
If L raises exceptions by language means, all is fine.
But if an exception happens on CPU, then the kernel gets it, and calls the exception handler on A.
Exception handler there starts doing it things, but knowing nothing of L it can't conceivably get it into consistent state and into the corresponding except{} block over there.

These are the problems i observed.
How are they solved or avoided?

My approach was to link the lib through a piece of code that pushes and pops the current affinity, so that memory allocated in the lib would be registered to the lib, as well as exception handlers.

Owen wrote:When a process wants to raise an exception, it calls _Unwind_RaiseException

The part i still can't find or get at, neither in Windows SEH specs berkus provided, nor in ABI overview, is what happens when exception is not raised by the process, but just happens.

What is the route from kernel to process's handling?