This is an archive of the discontinued LLVM Phabricator instance.

AArch64: Prefer FP-relative debug locations in HWASANified functions.
ClosedPublic

Authored by pcc on Jun 13 2019, 3:03 PM.

Details

Summary

To help produce better diagnostics for stack use-after-return, we'd like
to be able to determine the addresses of each HWASANified function's local
variables given a small amount of information recorded on entry to the
function. Currently we require all HWASANified functions to use frame pointers
and record (PC, FP) on function entry. This works better than recording SP
because FP cannot change during the function, unlike SP which can change
e.g. due to dynamic alloca.

However, most variables currently end up using SP-relative locations in their
debug info. This prevents us from recomputing the address of most variables
because the distance between SP and FP isn't recorded in the debug info. To
address this, make the AArch64 backend prefer FP-relative debug locations
when producing debug info for HWASANified functions.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jun 13 2019, 3:03 PM
pcc added a comment.Jun 13 2019, 3:04 PM

Oops, forgot to add a test. I'll do that in a bit.

pcc updated this revision to Diff 204640.Jun 13 2019, 3:24 PM
  • Add test

What if we do it the other way around - store SP instead of FP? SP is unusable for locals when there are dynamic allocas; FP is unusable when there is dynamic stack realignment; not sure which case is more common, but both should be rare enough. This could help with the code size at least a little.

pcc added a comment.Jun 14 2019, 11:20 AM

Don't we need frame pointers for fast stack traces anyway?

What if we do it the other way around - store SP instead of FP? SP is unusable for locals when there are dynamic allocas; FP is unusable when there is dynamic stack realignment; not sure which case is more common, but both should be rare enough. This could help with the code size at least a little.

Right, good point.

llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
1538 ↗(On Diff #204640)

should this be called ForDebugInfo, or something like that? It's not about signed immediate IMHO, it's about debug info having effectively infinite offset range.

pcc marked an inline comment as done.Jun 14 2019, 4:45 PM
pcc added inline comments.
llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
1538 ↗(On Diff #204640)

I thought about giving it a name like that, but it seems like the restriction is specific to the operand on certain load and store instructions referred to as <simm>, or a 9-bit signed immediate. If we were producing an immediate for a different instruction, we would want this to be false.

That said, maybe it should be called something like ForLdSt, then.

eugenis accepted this revision.Jun 21 2019, 2:53 PM

LGTM
I still think my suggestion for the name is best, but don't care about it too much.

This revision is now accepted and ready to land.Jun 21 2019, 2:53 PM
This revision was automatically updated to reflect the committed changes.