This reverts commit ad36e4284d66c3609ef8675ef02ff1844bc1951d, fixing a single uninitialized bit (which cannot be detected with Address Sanitizer). This PR adds support for the llvm-mc command-line flag "--gsframe" and adds ".sframe" to the legal values passed ".cfi_section". It plumbs the option through the cfi handling code a fair amount. Code to support actual section generation follows in a future PR. These options match the gnu-assembler's support syntax for sframes, on both the command line and in assembly files. First in a series of changes that will allow llvm-mc to produce sframe .cfi sections. For more information about sframes, see https://sourceware.org/binutils/docs-2.44/sframe-spec.html and the llvm-RFC here: https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900
This reverts commit f9d0bd02d966e5c28aca9a6ceadd5ffec6aa9f78.
This PR adds support for the llvm-mc command-line flag "--gsframe" and adds ".sframe" to the legal values passed ".cfi_section". It plumbs the option through the cfi handling code a fair amount. Code to support actual section generation follows in a future PR. These options match the gnu-assembler's support syntax for sframes, on both the command line and in assembly files. First in a series of changes that will allow llvm-mc to produce sframe .cfi sections. For more information about sframes, see https://sourceware.org/binutils/docs-2.44/sframe-spec.html and the llvm-RFC here: https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900
This change removes the `tidyLandingPads` function, which previously had a few responsibilities: 1. Dealing with the deletion of an invoke, after MachineFunction lowering. 2. Dealing with the deletion of a landing pad BB, after MachineFunction lowering. 3. Cleaning up the type-id list generated by `MachineFunction::addLandingPad`. Case 3 has been fixed in the generator, and the others are now handled during table emission. This change also removes `MachineFunction`'s `addCatchTypeInfo`, `addFilterTypeInfo`, and `addCleanup` helper fns, as they had a single caller, and being outlined didn't make it simpler. Finally, as calling `tidyLandingPads` was effectively the only thing `DwarfCFIExceptionBase` did, that class has been eliminated.
The existing behaviors and callbacks were overlapping and had very confusing semantics: beginBasicBlock/endBasicBlock were not always called, beginFragment/endFragment seemed like they were meant to mean the same thing, but were slightly different, etc. This resulted in confusing semantics, virtual method overloads, and control flow. Remove the above, and replace with new beginBasicBlockSection and endBasicBlockSection callbacks. And document them. These are always called before the first and after the last blocks in a function, even when basic-block-sections are disabled.
Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 . The class is mostly consistent now.
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121332
Identified with modernize-use-equals-default
The ARM backend was explicitly setting global binding on the personality symbol. This was added without any comment in a7ec2dcefd954, which introduced EHABI support (back in 2011). None of the other backends do anything equivalent, as far as I can tell. This causes problems when attempting to wrap the personality symbol. Wrapped symbols are marked as weak inside LTO to inhibit IPO (see https://reviews.llvm.org/D33621). When we wrap the personality symbol, it initially gets weak binding, and then the ARM backend attempts to change the binding to global, which causes an error in MC because of attempting to change the binding of a symbol from non-global to global (the error was added in https://reviews.llvm.org/D90108). Simply drop the ARM backend's explicit global binding setting to fix this. This matches all the other backends, and a large internal application successfully linked and ran with this change, so it shouldn't cause any problems. Test via LLD, since wrapping is required to exhibit the issue. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D110609
In terms of readability, the `enum CFIMoveType` didn't better document what it intends to convey i.e. the type of CFI section that gets emitted. Reviewed By: dblaikie, MaskRay Differential Revision: https://reviews.llvm.org/D76519