20

Just to note, I've read the questions and read the blog posts and I've also referenced the ABI.

What I completely don't understand is how that interacts with LLVM's EH intrinsics. The LLVM EH page gives a very vague overview- not exactly a checklist of "Implement X, Y, Z".

The LLVM EH page references the Itanium ABI directly. This would imply to me that LLVM only supports Itanium ABI exceptions. But I already know that Clang supports ARM and is developing support for Microsoft ABIs. So exactly how specific is LLVM's implementation of EH to the Itanium ABI?

When referencing the _Unwind stuff defined by Itanium ABI, is that obliged to be provided by a backend, or would I have to implement it for myself?

I also noticed that the LLVM IR generated by Clang does not reveal any language-specific tables, any exception frames, exception tables, or anything like that. In that case, how does LLVM know how to generate the language-specific data?

In short, how exactly do you go from LSDAs, EH contexts, and _Unwind_RaiseException to landingpad and resume?

Edit: Just for reference, I'm going to be JITting the resulting code on Windows.

Community
  • 1
  • 1
Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Typically, the only answer I got on the LLVM mailing list was "Read the source code of an existing open-source project that uses EH with LLVM". – Puppy Dec 28 '13 at 10:31

2 Answers2

8

Nowadays Itanium C++ ABI is de facto standard C++ ABI used on many other platforms. Itanium C++ ABI supports zero cost exception handling technique, which is the most widespread technique for today.

To support exception handling one must change the semantics of a function call. Now the calls fork the execution flow. One branch is taken when everything is fine and the second branch is taken in case of an exception. In LLVM IR there is the invoke instruction to call functions that may throw.

When the second branch is taken several kinds of actions may be performed:

  • call destructors (cleanup)
  • continue stack unwinding (resume)
  • enforce throw specifications (filter)
  • restore normal control flow (catch).

It's clear that some additional code must be generated to perform these actions. That's why we've got the landingpad instruction as well. It is the first instruction to be executed after invoke ends up with an exception.

But the main magic is performed at run-time. After an exception is thrown, the language agnostic runtime unwinds the stack, for every frame it finds language specific data area (LSDA) and calls language specific personality routine. The personality routine inspects program counter, LSDA and the current exception. It determines if any cleanup is necessary, if any throw specification is violated or if the exception can be caught by this frame.

As you probably know, all these data (personality routine, catched types, throw specification, cleanup actions) are already specified in landingpad instruction, so no additional data should be passed to the backend to generate exception-related sections in object file.

Nikolai
  • 1,499
  • 12
  • 24
  • Whilst I appreciate the effort, most of your answer is utterly wasted, as the question clearly indicates that I already know all of that. It could be accurately summarized as "LLVM hardcodes support for Itanium but then tries for some reason to pretend like it's not really hardcoded". – Puppy Nov 20 '14 at 22:16
  • Why are you so concerned about Itanium? Zero cost exception handling has got nothing specific to Itanium. – Nikolai Nov 23 '14 at 08:48
  • It clearly does in LLVM, because they don't support other zero-cost ABIs. – Puppy Nov 23 '14 at 09:53
  • What do you mean? What are "other zero-cost ABIs" that LLVM IR lacks support of? – Nikolai Nov 23 '14 at 10:54
  • SEH x64, for one. LLVM emits Itanium-specific unwind tables and suchlike things, so their implementation is Itanium-specific. – Puppy Nov 23 '14 at 16:39
  • SEH is NOT a zero cost EH. LLVM supports only zero-cost EH (and SjLj as a fallback). There might be different ABIs for zero-cost handling. For example, ARM EH EABI is somewhat different from Itanium EH ABI, but still they both follow the zero-cost approach. – Nikolai Nov 23 '14 at 17:08
  • SEH is only stack-based on x86. SEH x64 is pretty close to Itanium... in any case, since LLVM doesn't support either form of SEH, we can safely say that their implementation is quite coupled. – Puppy Nov 24 '14 at 14:00
5

The short answer is, LLVM effectively hardcodes support for every EH ABI it wants to support- ARM, Itanium, SEH, etc. So whilst the landingpad stuff might in theory be somewhat abstract, it's really not abstract at all and very tightly coupled, because the other half of stuff you need to do must be accomplished by the Itanium ABI EH support library that you need to do explicitly.

LLVM generates virtually all the EH implementation details, but you must also link to an Itanium EH support library at runtime. Other than that, the IR is really just what it shows- no additional effort required on behalf of the programmer.

I imagine things get much more sticky if you want to use non-Itanium.

Puppy
  • 144,682
  • 38
  • 256
  • 465