839fd9177e
When a pointer to a tracked alloca is passed to a call that may write through it (e.g. foo(&x)), the callee can modify the variable's stack home. The assignment tracking analysis didn't account for this, which could cause the debugger to show stale values after such calls. Consider: ``` int x = 1; foo(&x); // might set x to 99 x = 2; // store deleted by DSE ``` Without this patch, the analysis still thinks the stack home holds assignment `!id1` after the call. When it later sees the `dbg_assign` for the deleted store, the mismatch causes it to fall back to the old debug value (1) , which is wrong. Fix this by detecting calls where a tracked `alloca` escapes as an argument and treating them the same way we already treat untagged stores, set both `StackHome` and `Debug` to NoneOrPhi (unknown assignment) and keep `LocKind` as Mem (the stack slot is still the right place to look). This causes a `DBG_VALUE` with `DW_OP_deref` to be emitted after the call, telling the debugger to read whatever is actually in memory. Pointer arguments with readonly, readnone, or byval attributes are skipped since the callee either cannot modify the original memory or receives a copy. Intrinsics are also skipped since their memory effects are already modeled individually (e.g. memset/memcpy as stores, lifetime markers as no-ops). --------- Co-authored-by: Shivam Kunwar <phyBrackets@users.noreply.github.com>
117 KiB
117 KiB