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

via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 10 23:56:18 PST 2021


Hi Greg,

You are correct. I am including the section ‘Comparing toolchains’ from the llvm-dva
documentation, for a specific debug information issue detected in Clang.

See: https://bugs.llvm.org/show_bug.cgi?id=44884

-Carlos

Comparing toolchains
--------------------

In the previous section, we compared GCC and Clang. The current implementation
of llvm-dva have sufficient support for CodeView format, making possible the
comparison between MSVC and Clang compilers.

-----------------------------------------------------------------------
pr_44884.cpp
-----------------------------------------------------------------------
1  int bar(float Input) { return (int)Input; }
2
 3  unsigned foo(char Param) {
4    typedef int INT;                      // ** Definition for INT **
5    INT Value = Param;
6    {
7      typedef float FLOAT;                // ** Definition for FLOAT **
8      {
9        FLOAT Added = Value + Param;
10        Value = bar(Added);
11      }
12    }
13    return Value + Param;
14  }

The above test (from PR44884) is used to illustrates a scope issue found in
the Clang compiler.

See: https://bugs.llvm.org/show_bug.cgi?id=44884

The lines 4 and 7 contains 2 typedefs, defined at different lexical scopes.
4    typedef int INT;
7      typedef float FLOAT;

These are the logical views that llvm-dva generates for 3 different compilers
(MSVC, Clang and GCC), emitting different debug info formats (CodeView, DWARF)
on different platforms.

-----------------------------------------------------------------------
pr_44884_dw.o - Compiled with Clang (DWARF format).
-----------------------------------------------------------------------
Logical View:
[000]           {File} 'pr_44884_dw.o' -> elf64-x86-64
[001]             {CompileUnit} 'pr_44884.cpp'
[002]               {Producer} 'clang version 11.0.0
[002]     7         {Function} extern not_inlined 'bar' -> 'int'
[003]     7           {Parameter} 'Input' -> 'float'
[002]     9         {Function} extern not_inlined 'foo' -> 'unsigned int'
[003]                 {Block}
[004]    15             {Variable} 'Added' -> 'FLOAT'
[003]     9           {Parameter} 'Param' -> 'char'
[003]    13           {TypeAlias} 'FLOAT' -> 'float'
[003]    10           {TypeAlias} 'INT' -> 'int'
[003]    11           {Variable} 'Value' -> 'INT'

-----------------------------------------------------------------------
pr_44884_gc.o - Compiled with GCC (DWARF Format).
-----------------------------------------------------------------------
Logical View:
[000]           {File} 'pr_44884_gc.o' -> elf64-x86-64
[001]             {CompileUnit} 'pr_44884.cpp'
[002]               {Producer} 'GNU C++ 5.5.0 20171010'
[002]     7         {Function} extern not_inlined 'bar' -> 'int'
[003]     7           {Parameter} 'Input' -> 'float'
[002]     9         {Function} extern not_inlined 'foo' -> 'unsigned int'
[003]                 {Block}
[004]                   {Block}
[005]    15               {Variable} 'Added' -> 'FLOAT'
[004]    13             {TypeAlias} 'FLOAT' -> 'float'
[003]     9           {Parameter} 'Param' -> 'char'
[003]    10           {TypeAlias} 'INT' -> 'int'
[003]    11           {Variable} 'Value' -> 'INT'

-----------------------------------------------------------------------
pr_44884_cv.o - Compiled with Clang (CodeView format).
-----------------------------------------------------------------------
Logical View:
[000]           {File} 'pr_44884_cv.o' -> COFF-x86-64
[001]             {CompileUnit} 'pr_44884.cpp'
[002]               {Producer} 'clang version 11.0.0
[002]               {Function} extern not_inlined 'bar' -> 'int'
[003]                 {Parameter} 'Input' -> 'float'
[002]               {Function} extern not_inlined 'foo' -> 'unsigned'
[003]                 {Block}
[004]                   {Variable} 'Added' -> 'float'
[003]                 {Parameter} 'Param' -> 'char'
[003]                 {TypeAlias} 'FLOAT' -> 'float'
[003]                 {TypeAlias} 'INT' -> 'int'
[003]                 {Variable} 'Value' -> 'int'

-----------------------------------------------------------------------
pr_44884_ms.o - Compiled with MSVC (CodeView Format).
-----------------------------------------------------------------------
Logical View:
[000]           {File} 'pr_44884_ms.o' -> COFF-i386
[001]             {CompileUnit} 'pr_44884.cpp'
[002]               {Producer} 'Microsoft (R) Optimizing Compiler'
[002]               {Function} extern not_inlined 'bar' -> 'int'
[003]                 {Parameter} 'Input' -> 'float'
[002]               {Function} extern not_inlined 'foo' -> 'unsigned'
[003]                 {Block}
[004]                   {Block}
[005]                     {Variable} 'Added' -> 'float'
[004]                   {TypeAlias} 'FLOAT' -> 'float'
[003]                 {Parameter} 'Param' -> 'char'
[003]                 {TypeAlias} 'INT' -> 'int'
[003]                 {Variable} 'Value' -> 'int'

From the previous logical views, we can see that the Clang compiler emits both
typedefs at the same lexical scope (3), which is wrong, while GCC and MSVC emit
correct lexical scope for both typedefs.

---------+----------+----------------------------------------------------------
Compiler | Format   | Lexical Scope
---------|----------|----------------------------------------------------------
Clang    | DWARF    | [003]    13           {TypeAlias} 'FLOAT' -> 'float'
         |          | [003]    10           {TypeAlias} 'INT' -> 'int'
---------|----------+----------------------------------------------------------
GCC      | DWARF    | [004]    13             {TypeAlias} 'FLOAT' -> 'float'
         |          | [003]    10           {TypeAlias} 'INT' -> 'int'
---------|----------|----------------------------------------------------------
Clang    | CodeView | [003]                 {TypeAlias} 'FLOAT' -> 'float'
         |          | [003]                 {TypeAlias} 'INT' -> 'int'
---------|----------|----------------------------------------------------------
MSVC     | CodeView | [004]                   {TypeAlias} 'FLOAT' -> 'float'
         |          | [003]                 {TypeAlias} 'INT' -> 'int'
---------+----------+----------------------------------------------------------

Note: One of the main limitations while processing CodeView debug info, is the
reduced line information emitted for types and symbols, making difficult to use
the comparison feature within llvm-dva, as the line numbers are one of the
criteria for logical element match. In the meantime, any graphical comparison
tool is able to compare and show the logical view differences.

The above table shows the omitted line numbers for the referenced typedefs.


From: Greg Bedwell <gregbedwell at gmail.com>
Sent: 10 March 2021 20:48
To: Alexandre Ganea <alexandre.ganea at ubisoft.com>
Cc: Adrian McCarthy <amccarth at google.com>; Enciso, Carlos <Carlos.Enciso at sony.com>; James Henderson <jh7370.2008 at my.bristol.ac.uk>; Tobias Hieta <tobias at plexapp.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Debug information with clang-cl on Windows

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.

-Greg




On Wed, 10 Mar 2021 at 20:02, Alexandre Ganea via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:


De : Alexandre Ganea
Envoyé : March 10, 2021 3:02 PM
À : 'Tobias Hieta' <tobias at plexapp.com<mailto:tobias at plexapp.com>>; Adrian McCarthy <amccarth at google.com<mailto:amccarth at google.com>>; 'James Henderson' <jh7370.2008 at my.bristol.ac.uk<mailto:jh7370.2008 at my.bristol.ac.uk>>
Objet : RE: [llvm-dev] Debug information with clang-cl on Windows

DExTer can probably help bisecting to the specific optimization pass(es) that cause the debug infos to be omitted? https://lists.llvm.org/pipermail/llvm-dev/2018-August/125780.html

+James.

De : llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> De la part de Tobias Hieta via llvm-dev
Envoyé : March 10, 2021 2:26 PM
À : Adrian McCarthy <amccarth at google.com<mailto:amccarth at google.com>>
Cc : llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Objet : Re: [llvm-dev] Debug information with clang-cl on Windows

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify siee.postmaster at sony.com<mailto:siee.postmaster at sony.com>
This footnote also confirms that this email message has been checked for all known viruses.
Sony Interactive Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210311/c4ec2094/attachment-0001.html>


More information about the llvm-dev mailing list