[PATCH] D63469: hwasan: Teach the runtime to identify the local variable being accessed in UAR reports.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In D63469#1554412 <https://reviews.llvm.org/D63469#1554412>, @eugenis wrote:

> Please check what happens in "weird" cases with dynamic stack realignment or dynamic sp adjustment. If one or both of these cases can not be handled with this debug info format, can we at least avoid getting confused by them? Are we simply missing fp-offset in the debug info if the offset is not statically known? Add a test case.


In the case of dynamic sp adjustment, things seem to work just fine (for non-dynamic-alloca variables, which is the only kind that we instrument). I see a `DW_OP_fbreg` associated with each of the variables.

In the case of dynamic stack realignment,  the debug info is expressed relative to another register with the post-realignment frame address (usually x19), which means we end up using e.g. `DW_OP_breg19` instead of `DW_OP_fbreg` in the variable's `DW_AT_location`. We don't get confused by this sort of debug info because llvm-symbolizer only emits an fp offset if it see a `DW_OP_fbreg` in the location. I think it should be possible in principle to get this case to work by teaching the backend to use the post-realignment frame address register as `DW_AT_frame_base`, making the backend prefer `DW_OP_fbreg` for frames with stack realignment and creating a new intrinsic that returns the value of the `DW_AT_frame_base` designated register (whose value we would store in the ring buffer).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63469