New issue
Advanced search Search tips

Issue 749805 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocked on:
issue 753944

Blocking:
issue 636111



Sign in to add a comment

Debug visualizers don't work for Clang Windows

Project Member Reported by brettw@chromium.org, Jul 27 2017

Issue description

Switching the Clang compiler on seems to break VC's debug visualizers. It 

GN args:

target_cpu = "x64"
is_debug = true
is_clang = true
use_goma = false

Hovering over a string in Visual Studio 2017 with these flags shows std::_String_alloc.... gibberish that makes it almost impossible to tell what it is.

Switching to "is_clang = false" with the above args makes it work as expected.
 

Comment 1 by thakis@chromium.org, Jul 27 2017

Cc: r...@chromium.org
Labels: OS-Windows

Comment 2 by brettw@chromium.org, Jul 27 2017

Possibly relevant information:

John said he thought visualizers were always broken now. But the STL ones work reliably for me in a non-Clang build.

The Chrome-specific visualizers seem completely broken both with and without Clang in VS2017 (I don't have 2015 any more to check). These are the ones in //tools/win/DebugVisualizers. I did some checking and it appears the .natvis files do still get added to the .pdb file.

Comment 3 by thakis@chromium.org, Jul 31 2017

I think this is supposed to pass the /natvis flags to link.exe: https://cs.chromium.org/chromium/src/tools/win/DebugVisualizers/BUILD.gn?q=natvis+file:%5C.gn&sq=package:chromium&l=10

This seems to be present in the generated .ninja files at least.

Comment 4 by r...@chromium.org, Aug 8 2017

This seems to be a problem when the dynamic CRT (/MD) is used. I think gn defaults to component builds, and component builds probably use the dynamic CRT. This is what I see in VS with /MD.
string-visualizer-dynamic.png
55.3 KB View Download

Comment 5 by r...@chromium.org, Aug 8 2017

Owner: r...@chromium.org
I think this is because the natvis visualizers match the exact type names emitted by MSVC, and clang's type names don't *quite* match MSVC's. Here is a snippet from stl.natvis for visualizing a std::string:
  <Type Name="std::basic_string&lt;char,*&gt;">

Clang emits spaces between template arguments, and MSVC does not. Compare these two lines:
    Name: std::basic_string<char, std::char_traits<char>, std::allocator<char> >
    Name: std::basic_string<char,std::char_traits<char>,std::allocator<char> >

I think this will be easy to fix. We already have a flag in the type printer to help us match MSVC names.

Comment 6 by r...@chromium.org, Aug 8 2017

Well, that can't be the cause, since that glob should match regardless of the name spacing. There's more surface-level differences worth investigating, though.

Comment 7 by r...@chromium.org, Aug 8 2017

My next theory is that these natvis conditions fail to evaluate:
      <DisplayString Condition="_Mypair._Myval2._Myres &lt; _Mypair._Myval2._BUF_SIZE">{_Mypair._Myval2._Bx._Buf,na}</DisplayString>

_BUF_SIZE isn't mentioned anywhere in clang's debug info for std::string.

So, the next thing to do is to make sure we describe _BUF_SIZE the way that MSVC does in this small example:

struct Foo {
  enum { _BUF_SIZE = 16 };
  int x[_BUF_SIZE];
};
Foo f;

Comment 8 by r...@chromium.org, Aug 8 2017

I was able to visualize std::string in a small program after LLVM r310410.

The next thing we need to do is roll clang.
Blockedon: 753944
Status: Fixed (was: Untriaged)
Roll landed Saturday, so this should work now -- at least it does in small programs. Please reopen if you're still seeing issues in this area.

Sign in to add a comment