codeview: windbg can't show local on-stack parameter for simple clang-cl built program

[nico]

Bugzilla Link	43920
Version	unspecified
OS	Windows NT
CC	@amykhuang,@jmorse,@zygoloid,@rnk

Extended Description

I have a simple program:

C:\src\hack\pdb>type file.cc int f(int i); int main() { return f(42); }

C:\src\hack\pdb>type subdir\file2.cc int f(int i) { return i; }

I build it like so:

clang-cl /Z7 -c file.cc clang-cl /Z7 -c subdir\file2.cc lld-link /debug /pdbaltpath:%_PDB% file.obj file2.obj

And debug like so:

C:\src\hack\pdb>windbg -c "bp file!f; g; dv" file.exe

I get

Breakpoint 0 hit i =

If I use cl instead of clang-cl, it shows up fine.

Note that this isn't an optimized build.

[rnk]

I guess this was https://crbug.com/773047

[rnk]

This proposed change to LLVM IR from 2016 would've made this a little less awkward: http://lists.llvm.org/pipermail/llvm-dev/2016-December/107918.html But it was pretty roundly rejected. :(

[rnk]

I think this is known. jam@chromium.org reported something along these lines.

The issue is that Clang homes all parameters into local allocas at -O0. This means that parameters are not available at the top of the function. You have to step into the function before they become available. For a single line function, this is unfortunately impossible, there's no where to step, single stepping will take you to the epilogue.

If you compile the same program for x64 with cl, windbg shows me this:

0:000> bp t!f; g; dv *** WARNING: Unable to verify checksum for t.exe Breakpoint 0 hit i = 0n7

The value of i is not 7, it should be 42, but the breakpoint is set prior to the store of ECX to the variable's stack slot described by the debug info.

Fixing this involves telling the debugger where the function prologue ends. I don't know of a way to express that right now.

[nico]

If you don't want to copy-paste the code, you can also run:

git clone https://github.com/nico/hack.git cd hack\pdb build debug

This requires that you have clang-cl and lld-link and windbg on your path (windbg is at C:\Program Files (x86)\Windows Kits\10\Debuggers\x64), and that you're in a 64-bit msvc cmd window.

[nico]

Also happens with today's trunk.

[nico]

Am I holding things wrong somehow?

Is this a known problem?

I'm at caaf827c244b16f, ca 3 weeks old.