Exception handling support

[luismarques]

Currently the code generation seems to optimize away everything but the no-throw code path. What's needed for generating code for the rest of the IR code paths? (e.g. landingpad, etc.).

By working around the current backend limitations regarding atomics and TLS, I have the D language runtime working. Yet, many parts of the standard library will misbehave due to throw exceptions not being handled. This ends up impacting functionality that would normally work even without exceptions. Given that this is the only major issue that seems to remain for proper D RISC-V support, adding this functionality would be most appreciated.

[luismarques]

I had some success by setting ExceptionsType = ExceptionHandling::DwarfCFI and changing the configuration in MCObjectFileInfo.cpp to use .ubyte4 instead of .uleb128. Regarding the backend, there are some problems with the optimization passes using a non-existent register when exceptions are used. Regarding D, the D frontend seems to affect the configuration somehow and still uses .uleb128. So I'm working on fixing those.

[luismarques]

More details: I had to change EHStreamer.cpp to use EmitLabelDifference instead of EmitLabelDifferenceAsULEB128 in a few places. The generated table is now probably correct, as can be seen by the fact that the catch block is now actually executed (but eventually crashes in __cxa_end_catch with a misaligned instruction access). That only works for textual assembly output (which to be assembled one must currently replace two .uleb128 with .byte). For object file output the exception table doesn't have the relocations generated properly. I'll have to figure out why.

[luismarques]

OK, the crashes were because there was no implementation of getExceptionPointerRegister and getExceptionSelectorRegister. I'm assuming those should return X10 and X11 (a0 and a1). Although it would be nice to have that confirmed. Now I think we only need to have the stack adjustment CFI directives for the textual assembly to be completely correct.

[luismarques]

(it also fixed the error about using a non-existent register, when optimizations are enabled; the problem with missing relocations persists though)