[llvm-dev] Debug information with clang-cl on Windows

Tobias Hieta via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 10 11:25:54 PST 2021


Hello,

Thanks for your reply!

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.

Thanks,
Tobias.

On Wed, 10 Mar 2021 at 00:45, Adrian McCarthy <amccarth at google.com> wrote:

> 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.
>
> On Tue, Mar 9, 2021 at 2:46 PM David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> On Tue, Mar 9, 2021 at 12:37 AM Tobias Hieta via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello,
>>>
>>> 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.
>>>
>>> Our command line is:
>>>
>>> clang-cl.exe /nologo -DUNICODE -DUSE_BREAKPAD -DWIN32
>>> -DWIN32_LEAN_AND_MEAN -DWINVER=0x0601 -D_CRT_NONSTDC_NO_DEPRECATE
>>> -D_CRT_SECURE_NO_WARNINGS -D_LEGACY_NAT_TRAVERSAL_ -D_REENTRANT
>>> -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS
>>> -D_UNICODE -D_WIN32_WINNT=0x0601 -D_WINSOCK_DEPRECATED_NO_WARNINGS
>>> -Iincludes -m32 -fdiagnostics-absolute-paths
>>> --target=i686-windows-msvc -m32 /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0
>>> /Od /RTC1 -MDd /Zm512 /EHsc /bigobj /W3 -Werror -Wsign-compare
>>> -Wno-reorder-ctor -Wno-delete-non-virtual-dtor -Wunused-variable
>>> -Wuninitialized -std:c++14
>>>
>>> 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?
>>>
>>> Thanks,
>>> Tobias
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210310/7c665bd3/attachment.html>


More information about the llvm-dev mailing list