Screenshots attached.

	clang.png 116 KB View Download

	msvc.png 310 KB View Download

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.

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?

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

I was able to reproduce this. I'll keep investigating and post more later.

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.

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.

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.

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

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