[PATCH] D114443: [DebugInfo][InstrRef] Cope with win32 calls changing the stack-pointer in LiveDebugValues

[Jeremy Morse via Phabricator via llvm-commits]

jmorse created this revision.
jmorse added reviewers: StephenTozer, Orlando, TWeaver, djtodoro.
Herald added subscribers: pengfei, hiraditya.
jmorse requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This patch works around an edge case in win32 environments that could produce false addresses for variable length arrays.

Most of LiveDebugValues (VarLoc and InstrRef) is written with the assumption that register defs of the stack pointer on call instructions should be ignored -- the call instruction certainly alters SP, but the stack is balanced when the call returns [0]. Unfortunately there's a single scenario where this definitely isn't true: on 32-bit Windows, with variable-length arrays, we call a function `_chkstk` that both probes the stack and alters the stack pointer. With DBG_VALUE based variable locations, this isn't a huge problem: a DBG_VALUE is applied to the stack pointer after the function returns, and is then copied to other registers. However in instruction referencing mode, we need to instrument the instruction defining the value (see next patch): that means the call to `_chkstk`, which violates the above assumption that calls don't define the stack pointer.

This patch adds an exception: we add a target frame-lowering hook to see whether stack probe functions will modify the stack pointer, store that in an internal flag, and if it's true then scan CALL instructions to see whether they're such badly-behaved functions. If they are, we recognise them as defining a new stack-pointer value. If we don't do this, then LiveDebugValues will always think "the dynamic allocas address is always whatever the current stack pointer is", which is going to produce false locations if more than one dynamic alloca is used.

The added test exercises this behaviour: two calls to `_chkstk` should be considered as producing two different values.

[0] This isn't true of stdcall, but I think we have existing difficulties with that anyway.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114443

Files:
  llvm/include/llvm/CodeGen/TargetFrameLowering.h
  llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
  llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/test/DebugInfo/MIR/InstrRef/win32-chkctk-modifies-esp.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D114443.389203.patch
Type: text/x-patch
Size: 14292 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211123/67ce40e2/attachment.bin>