We recently switched our windows builds from the CL compiler to
clang-cl. This was a pretty big jump in terms of code generation and
having a uniform compiler across all the major platforms.
Our setup is that our Windows developer use MSVC as the IDE and
compile with our own build of clang-cl and link with lld-link.
Some of the developers noticed that some of the debug information are
not as good as with CL. Or rather some variables seems to be optimized
out, this is what the IDE says, see attached screenshot. I have tried
to figure out if there is a rhyme and reason to what variables are
gone - but I have not been able to see any pattern.
Is there any good way to debug this or is it a known limitation with
clang-cl or 32 bit (we don't do 64 yet - but with clang-cl we hope to
move towards that soon). Or am I missing some flags?
I would guess there’s no one bug here - debug info quality (specifically/especially the location of variables when compiling with optimizations enabled) is a long tail/sliding scale of issues. LLVM is, on the whole, not spectacular at this - a matter of bugs to fix, some small/simple, others more systemic/representational.
If you’re interested in contributing to this work - generally the first step is to isolate the problem - first thing you can do is if you have some experience dumping/examining debug info in object files, you can dump/examine the relevant object files then try to reduce/remove code from the relevant objects, etc, to see what the minimal example is that’ll make it easier to figure out how to fix.
I believe that, even with /Od (that’s Microsoft for “disable optimizations”), clang-cl applies some optimizations.
People on my team have been fixing debug info quality bugs for Windows for a while. I don’t have specific knowledge of these issues, but it’s possible newer versions (like 12 or head) may have solved this. We’re somewhat more focused on 64-bit than 32-bit builds, so you might encounter some differences there.
If you can reproduce the problem with a reduced code sample, please file a bug with all the deets. If you do some debugging yourself, please let us know what you find.
Is it possible to disable optimisations with clang-cl and see if that makes a difference?
I will also try to build with clang 12 instead and see if there is any improvement.
Happy to try to reproduce or fix the issue - but I am unfamiliar with this debug info on windows and how to even start looking into it, any pointers are appreciated.
Is it possible to disable optimisations with clang-cl and see if that makes a difference?
I will also try to build with clang 12 instead and see if there is any improvement.
Happy to try to reproduce or fix the issue - but I am unfamiliar with this debug info on windows and how to even start looking into it, any pointers are appreciated.
I’m glad to hear things are working reasonably well for you.
Regarding variables marked as optimized out, the main issue that I’m aware of has to do with parameters at function entry. We had a user report this as https://crbug.com/755841.
What you have in the screenshot doesn’t seem related to parameters. It seems like this issue could be specific to 32-bit x86. We can definitely take a look at a more detailed bug report if you find the time to file one, but as Adrian mentioned, 64-bit is becoming the better tested, more robust, target.
llvm-dva (not yet in tree but see https://reviews.llvm.org/D88661 ) might also be useful here depending on how mature the codeview support is (cc Carlos - please correct me if anything I said is wrong!).
I think, in theory it should allow us to do a direct comparison between the debug info generated by clang-cl, and that generated by cl.exe for the same code (and also with clang’s DWARF output if that’s possible to generate too) so we can see exactly what the differences are and what’s missing.
When I previously looked into some of this stuff using dexter I found a few examples like https://bugs.llvm.org/show_bug.cgi?id=37682 where clang was comparing unfavorably with MSVC because it was doing more aggressive loop optimizations. I don’t know how widespread it is or whether it’s still the case in more recent versions, but I certainly ran into it on more than one occasion where MSVC was doing things like leaving stores in loops whereas clang would hoist it instead for better codegen but an unfortunately worse debugging experience.
I’m not the person to ask DExTer questions (I just fixed a few tests that were causing me bother with regards to the cross-project-tests proposal). You’ll want someone like Jeremy Morse (CC’ed).
On the Dexter front, I've found it most useful for small tests in a
very tight loop, i.e. modifying a source file and quickly getting some
feedback about what kind of debug-info defects are present.
Alternately, with opt-bisect-limit to find passes that contribute
defects. However, it doesn't work so well with large code bases, we're
actively pursing improving that.
There are a few variable-location-coverage improvements in the works
-- Stephens patches [0] for variadic variable locations are just
landing, although I don't believe they'll be useful for CodeView/PDB
targets.
More bug reports about variable locations dropped by clang would be
great as we receive very few of them, they're usually not a blocker to
developers. Any patterns in what variables go missing would be
especially interesting, i.e. "they're usually in lambdas" or "many are
loop iterators". That'd help us focus increased testing on those
areas.
