[llvm-dev] MTE -- discussion on Exception unwinding ABI (original) (raw)
Matthew Malcomson via llvm-dev llvm-dev at lists.llvm.org
Mon May 11 02:12:52 PDT 2020
- Previous message: [llvm-dev] MTE -- discussion on Exception unwinding ABI
- Next message: [llvm-dev] Incorrect behavior in the LLVM dependence analyzer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05/05/2020 01:32, Evgenii Stepanov wrote:
Approach 1 sounds perfect to me. Conveniently, both unwinders ignore unrecognized characters in the augmentation string. In our experience with ASan, errors caused by failing to unpoison/untag a stack frame are cryptic, and pretty hard to debug. But they can be caused by a number of other things, not just the unwinder - vfork, longjmp and friends in libc, custom stack manipulation anywhere (ex. ART has longjmp implemented in assembly). We could implement a "verified" mode to catch these cases - a compilation flag that checks that the entire frame is SP-accessible at function entry. We could use the letter "G" as that's what stands for "tag" in the instruction mnemonics (STG, IRG).
Awesome -- and the "G" letter seems like a good idea to me.
I'll wait until the end of the week to give others a chance to comment, but if no-one objects by then I think we can go ahead with Approach 1 using the letter "G".
I had a thought about extending Dwarf with a way to specify a range of offsets to be untagged within the frame (and default to the entire frame if not specified). But it feels like the performance savings would not be worth the extra complexity.
- Previous message: [llvm-dev] MTE -- discussion on Exception unwinding ABI
- Next message: [llvm-dev] Incorrect behavior in the LLVM dependence analyzer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]