In the future Windows will enable Control-flow Enforcement Technology (CET aka shadow stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.
This change allows llvm to generate the section that contains the appropriate symbol references in the form expected by the msvc linker.
This feature is enabled through a new module flag, ehcontguard, which was modelled on the cfguard flag.
The change includes a test that when the module flag is enabled the section is correctly generated.
The set of exception continuation information includes returns from exceptional control flow (catchret in llvm).
In order to collect catchret we:
- Includes an additional flag on machine basic blocks to indicate that the given block is the target of a catchret operation,
- Introduces a new machine function pass to insert and collect symbols at the start of each of each block, and
- Combines these targets with the other EHCont targets that were already being collected.
Change originally authored by Daniel Frampton <dframpto@microsoft.com>
For more details, see MSVC documentation for /guard:ehcont
https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-eh-continuation-metadata
If we do use this name, I would prefer to use as short a name as possible. C++ names are long enough that they significantly contribute to object file size. Let's use getFunctionNumber() here instead, so we get names like $ehgcr_2_42. You'll need a non-digit separator to ensure the names are unique (consider function 5 bb 55 and function 55 bb 5).
This wasn't as much of a concern for longjmp tables, since setjmp is less common and mostly appears in C code.