Userspace: Exception Handling

[ADKaster]

• LibUnwind: Create a replacement for the stack unwinding library facilities in libgcc.a
  • [x] Analyze the Itanium exception handling ABI and the i386 System V processor specific ABI for the expected _Unwind_* definitions
  • [ ] Implement Base ABI
    • [ ] Using SJLJ exceptions? (gross!)
    • [ ] Using DWARF .eh_frame Common Frame Information exceptions (modern!)
    • [ ] Create custom implementation of personality routine __gxx_personality_v0 (if .eh_frame_hdr) or __gxx_personality_sj0 (if using setjump/longjump)
  • [ ] Configure GCC to use --with-system-libunwind so that it doesn't build _Unwind_* symbols into libgcc.a
• LibC: Implement Itanium C++ abi for exception throwing and catching
  • [ ] Analyze Itanium exception handling ABI part II for what __cxa_* methods are required
  • [ ] Look into what Itanium ABI methods are required to support type info?
    • [ ] Implement whatever is necessary to make RTTI work.
  • [ ] Make it possible to call __cxa_throw, cxa_begin_catch, cxa_unexpected, etc
• LibDebug: Parse CIEs and FDEs from .eh_frame and .debug_frame ELF sections
  • [ ] Note that .eh_frame uses version 1 and .debug_frame uses version pick-your-favorite-DWARF-revision (4?)
  • [ ] Parse EH Frame header or debug frame header using ByteBuffers into a list of Common Information Entries and Frame Description Entries
  • [ ] Identify all the common frame state machine instructions that the exception info and debug info sections are telling us to do in all these CIE objects
  • [ ] Make a parser/execution state machine for running the important frame instructions on a frame
  • [ ] Fold into backtrace capability for LibDebug, and better exception handling

[bugaevc]

But why?..

Let's maybe not have exceptions?

[ADKaster]

Why not?

Need to parse the frame information to get reasonable debugging backtraces and such, might as well go the extra mile to get exceptions in userspace.

On Thu, May 14, 2020, 1:17 AM Sergey Bugaev notifications@github.com wrote:

But why?..

Let's maybe not have exceptions?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SerenityOS/serenity/issues/2216#issuecomment-628439714, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB777DTBY5GOT2BNGVGN5E3RROLIFANCNFSM4NAMOTNA .

[awesomekling]

Seems fine to support it if it's relatively non-invasive.

[awesomekling]

Just to be clear, the absence of exceptions in this project is a feature.

But we can still support it for ports :)

[bugaevc]

As long as we can make it not allocate a page upfront for bullshit reasons in each process, and as long as it doesn't cause all our methods to grow unwinding paths when built with exception support...

[awesomekling]

Indeed, this feature needs to have zero impact on the stock system. My understanding of LibUnwind is that everything necessary for exception support would go in there and unless you link against it, none of this affects you. :)

[ADKaster]

Growing non exceptional code when built with exceptions is a feature it setjump/longjump exceptions. The compiler has to set the jump buffer before calling a possibly throwing method.

There's a reason the two phase lookup ABI based on call frame information was developed, and it's specifically to give "zero overhead" exceptions. If you don't throw, nothing happens to your code.

That being said I'm looking into this mostly as an academic thing, because it looks like a cool technical challenge. Not looking to add try catch all over the place :).

On Thu, May 14, 2020, 3:00 AM Andreas Kling notifications@github.com wrote:

Indeed, this feature needs to have zero impact on the stock system. My understanding of LibUnwind is that everything necessary for exception support would go in there and unless you link against it, none of this affects you. :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SerenityOS/serenity/issues/2216#issuecomment-628498422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB777DSN7CGPMDCFLBGYH5TRROXK5ANCNFSM4NAMOTNA .

[bugaevc]

There's a reason the two phase lookup ABI based on call frame information was developed, and it's specifically to give "zero overhead" exceptions. If you don't throw, nothing happens to your code.

It's true that no special setup is needed to call a potentially throwing method when the so-called zero cost exceptions are used. But you still pay by way of the exception handling code the C++ compiler inserts on your behalf (that runs object destructors) — if any call can potentially throw (as far as the compiler is concerned — we know we don't throw exceptions) that could a lot of additional code — so I'm concerned about executable size, cache friendliness and such.