Symbols don't always show up when using clang-cl |
|
||
Project Member Reported by lfg@chromium.org, Oct 19 2016 | Back to list | ||
Issue descriptionVersion: 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.
Oct 19 2016
,
Screenshots attached.
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.
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_.
Dec 6 2016
,
rnk, amccarth: what was the current status here?
Dec 6 2016
,
I think the status is that I missed the c#4 update and need to try following those steps to reproduce.
Dec 16 2016
,
I was able to reproduce this. I'll keep investigating and post more later.
Dec 16 2016
,
I suspect the important difference between my previous configuration and the current one is "is_win_fastlink = true".
Dec 16 2016
,
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.
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.
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.
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
Dec 22 2016
,
I can confirm things work after http://crrev.com/440163. Closing, thanks for the report and prodding. :) |
|||
►
Sign in to add a comment |
Comment 1 by thakis@chromium.org
, Oct 19 2016Cc: r...@chromium.org amccarth@chromium.org
Labels: clang OS-Windows
Owner: ----