[PATCH] D139024: [Backend][AsmPrinter][CFI] Generate unwind table entries in .eh_frame when the uwtable attribute is present.

[Juan Manuel Martinez Caamaño via Phabricator via llvm-commits]

jmmartinez added a comment.

I'm coming back to this issue after a long time.

---

> I am still unclear what you want to do. A .c source with a command line in the commit message will help, though I guess this patch may not be needed at all.

Here's an example of what I would like to achieve:

Consider the vadd_hip.cpp example <https://github.com/ROCm-Developer-Tools/HIP-CPU/blob/master/examples/vadd_hip/vadd_hip.cpp>
but with the bounds check at line 18 <https://github.com/ROCm-Developer-Tools/HIP-CPU/blob/master/examples/vadd_hip/vadd_hip.cpp#L18> removed.

The user can compile this code using the command line below:

  hipcc -fsanitize=address vec_add.cpp

The previous command triggers two clang invocations:

- For the device: `clang-15 -cc1 -triple amdgcn-amd-amdhsa -target-cpu gfx90a ... vadd_hip.cpp -funwind-tables=2 -fsanitize=address`
- For the host: `clang-15 -cc1 -triple x86_64_unknown-linux-gnu ... -fsanitize=address`

Ideally, during the execution the out-of-bounds memory access would be detected by asan on the device side and a stacktrace reported.

At the moment, unwinding is not supported on the device side (neither fast nor slow), but having the CFI entries in the `.eh_frame` would remove a block to advance towards it.

---

When I started addressing the problem I realized two things:

- On clang's driver side, `-fsanitize=address` seems to imply that asynchronous unwind tables are used. Which sets all function with the attribute `uwtable`
- On targets that support DwarfCFI, unless the EH-type is DwarfCFI, CFI entries in are not generated for functions marked as `uwtable`.

I would have expectedt that functions marked with the `uwtable` attribute would get their entry regardles of the target's EH-type (doing this is the solution I propose).

An alternative solution could be to make the EH-type of AMDGPU be DwarfCFI (this could work, but I don't know if there are other consequences).

---

> -fsanitize=address used to need unwind tables for error reporting. It no longer does after https://reviews.llvm.org/D102046

Finally, since I hace many blindspots on this part of LLVM, and for my curiosity, would you mind explaining the tradeoff between the slow and fast unwind?
If I understand, there is a difference in performance; and that there slow-unwind uses libunwind, while fast-unwind is implemented directly in compiler-rt. But I'm not sure if there are other implications from this tradeoff.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139024/new/

https://reviews.llvm.org/D139024