New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 657518 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Dec 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

issue 636111

Sign in to add a comment

Symbols don't always show up when using clang-cl

Project Member Reported by, Oct 19 2016

Issue description

Version: ToT
OS: Windows

What steps will reproduce the problem?
(1) Build chrome with clang-cl on windows.
(2) Set a breakpoint in RenderFrameHostManager::SetRenderFrameHost
(3) Launch chrome attached with visual studio. The breakpoint will hit.
(4) Try to expand render_frame_host_.

What is the expected output?
We should see members of RenderFrameHost.

What do you see instead?
Symbols don't work.

Symbols work in this particular example when building with MSVC.


Comment 1 by, Oct 19 2016

Blocking: 636111
Labels: clang OS-Windows
Owner: ----

Comment 2 by, Oct 19 2016

Screenshots attached.
116 KB View Download
310 KB View Download

Comment 3 by, Oct 24 2016

I tried to reproduce, but I wasn't able to get a breakpoint to fire there. I tried running with and without --single-process. Do I need to do something special to activate it? I built Chromium at crrev 426811.

Just from looking at the build configuration and symptoms, this looks a lot like , but I don't think it's the same issue. RenderFrameHostImpl is marked CONTENT_EXPORT, but the breakpoint is in the content component, so there shouldn't be any cross-dll type resolution issues.

Comment 4 by, Oct 28 2016

Here are the command-line flags I'm using: "--no-sandbox about:blank".

is_debug = true
is_component_build = true
is_win_fastlink = true
goma_dir = "d:\dev\goma-win64"
enable_nacl = false
enable_google_now = false
is_clang = true
use_goma = true

And the breakpoint is set here: (first line in RenderFrameHostManager::SetRenderFrameHost, with std::unique_ptr<RenderFrameHostImpl> old_render_frame_host = ...).

And I'm trying to look at this->render_frame_host_.

rnk, amccarth: what was the current status here?

Comment 6 by, Dec 6 2016

I think the status is that I missed the c#4 update and need to try following those steps to reproduce.

Comment 7 by, Dec 16 2016

Status: Assigned (was: Untriaged)
I was able to reproduce this. I'll keep investigating and post more later.

Comment 8 by, Dec 16 2016

I suspect the important difference between my previous configuration and the current one is "is_win_fastlink = true".
is_win_fastlink = true continues to have some limitations.

It means that DIA2 cannot iterate through all symbols - this makes fastlink inappropriate for doing build-size regression testing, at least not using my techniques.

fastlink makes VS memory profiling impossibly slow.

I think I hit some other limitations, but I can't find them now. If is_win_fastlink doesn't work with clang-cl then I'll have to start documenting these limitations. So far they have mostly been issues that only I would ever hit.

Comment 10 by, Dec 16 2016

I really hope we can fix this. Since clang-cl doesn't use PDBs and embeds the debug info into the object files, disabling is_win_fastlink causes the linking time to be painfully slow.

Comment 11 by, Dec 16 2016

fastlink seems to work with MSVC /Z7, so in general fastlink should work with clang.

We can fix this specific issue by emitting more type information, but it comes with a 17% object file size hit:
If you just look at .debug$T sections, they grow by 35%.

Here's the CL to flip the option:

We can win back some of the gains in Chromium by passing -flimit-debug-info to clang when we know we're not doing fastlink builds.
Project Member

Comment 12 by, Dec 21 2016

The following revision refers to this bug:

commit 482876ffc87c08dcd8474001eec6d0717f41c4eb
Author: rnk <>
Date: Wed Dec 21 18:39:57 2016

Make is_win_fastlink imply -fstandalone-debug for clang

Visual Studio can't find type information outside of the object file
currently being debugged with /DEBUG:FASTLINK. So, every object file
needs to have "standalone" debug information in this mode. However, that
generates a lot more debug info and slows down normal links, so only do
this when we know fastlink is in use.

While we're at it, explicitly pass -fno-standalone-debug to clang when
we're not using is_win_fastlink. This will make sure Chromium keeps using
limited debug info if clang switches the default for -fstandalone-debug.,
BUG= 657518 

Cr-Commit-Position: refs/heads/master@{#440163}


Comment 13 by, Dec 22 2016

Status: Fixed (was: Assigned)
I can confirm things work after Closing, thanks for the report and prodding. :)
33.0 KB View Download

Sign in to add a comment