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
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocking:
issue 636111



Sign in to add a comment

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

Project Member Reported by lfg@chromium.org, 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 thakis@chromium.org, Oct 19 2016

Blocking: 636111
Cc: r...@chromium.org amccarth@chromium.org
Labels: clang OS-Windows
Owner: ----

Comment 2 by lfg@chromium.org, Oct 19 2016

Screenshots attached.
clang.png
116 KB View Download
msvc.png
310 KB View Download

Comment 3 by r...@chromium.org, 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  http://crbug.com/642812 , 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 lfg@chromium.org, Oct 28 2016

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

args.gn:

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: https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?l=2446 (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 r...@chromium.org, 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 r...@chromium.org, Dec 16 2016

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

Comment 8 by r...@chromium.org, 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 lfg@chromium.org, 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 r...@chromium.org, 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: https://bugs.chromium.org/p/chromium/issues/detail?id=642812#c15
If you just look at .debug$T sections, they grow by 35%.

Here's the CL to flip the option: https://reviews.llvm.org/D27858

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 bugdroid1@chromium.org, Dec 21 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/482876ffc87c08dcd8474001eec6d0717f41c4eb

commit 482876ffc87c08dcd8474001eec6d0717f41c4eb
Author: rnk <rnk@chromium.org>
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.

R=thakis@chromium.org,brucedawson@chromium.org
BUG= 657518 

Review-Url: https://codereview.chromium.org/2587603002
Cr-Commit-Position: refs/heads/master@{#440163}

[modify] https://crrev.com/482876ffc87c08dcd8474001eec6d0717f41c4eb/build/config/compiler/BUILD.gn

Comment 13 by r...@chromium.org, Dec 22 2016

Status: Fixed (was: Assigned)
I can confirm things work after http://crrev.com/440163. Closing, thanks for the report and prodding. :)
render_frame_host_repro.png
33.0 KB View Download

Sign in to add a comment