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

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocked on:
issue 645953

Blocking:
issue 636111



Sign in to add a comment

Some variables are missing drop-down arrows in MSVC's debugger when building with clang-cl

Project Member Reported by scottmg@chromium.org, Aug 31 2016 Back to list

Issue description

At eca2d62e8ed9d068f34c0241d5b748c51bc0b2b5 r415638 clang 280106, still missing various debug info.

[plznav-toolbar-2]d:\src\cr3\src>type out\debug\args.gn
is_debug = true
is_component_build = true
win_linker_timing = true
enable_nacl = false
is_chrome_branded = true
target_cpu = "x86"
win_console_app = true
symbol_level = 2
is_clang = true

Build unit_tests.exe, and debug --gtest_filter=PrintPreviewDialogControllerUnitTest.CloseDialogOnNavigation

See attached image for clang results. I'll attach cl's version once I've rebuilt and confirmed it's not somehow a general thing.
 
missing-debug-info.png
394 KB View Download

Comment 2 by thakis@chromium.org, Aug 31 2016

Blocking: 636111
Hmm, it's actually not much better in cl until I cast to a concrete type.

So now I'm not sure what my feature request is.

One difference is that I can at least look through the __vfptr to see what the concrete type is in the cl build. I don't know how important that really is though.
cl.png
424 KB View Download

Comment 4 by thakis@chromium.org, Aug 31 2016

Can you comment more on

a) what cl does that clang-cl doesn't
b) what both don't do but wish they did?

i.e. unredux a bit :-)

Comparing the screenshots, I see:
* nav_controller and web_controller in the watch window have dropdown arrows in the cl screenshot but not in the clang-cl one
* same for &nav_controller and nav_controller in the Autos box at the bottom
* Lang in "call stack" on the right is "C++" in the cl screenshot but "Unknown" with clang-cl
* Also in the "call stack" table some line numbers are different -- is that just due to inlining?

It's not clear to me which of these differences are bugs -- probably all of them (except maybe for the last)?

Comment 5 by thakis@chromium.org, Aug 31 2016

Cc: r...@chromium.org
Sorry, yes, I was thinking the first two (which are basically the same thing).

I don't know of any problem that the 3rd one (Lang) creates.

The 4th could be that I pulled or updated code. I haven't noticed any line numbers being incorrect.
> One difference is that I can at least look through the __vfptr to see what the concrete type is in the cl build.

That doesn't quite show in the CL screen shot, but I think I know what you mean.

I think this is the inverse of the original problem, where we didn't have complete type info for a concrete class because the base class type info was in another component.  I believe that's fixed.  In this case, the component knows about the base class type (which is of limited interest since it's an abstract base class).  But the type info for the derived class may come from some other component and was never brought into this one because it wasn't necessary just to call virtual methods declared in the base.

It would be nice to see the virtual function pointer for nav_controller.  I see Reid submitting some changes to vfptr debug info, but I'm not certain if they relate to this issue.

I don't know whether we'll be able to map the vfptr to the concrete class on all cases.  I think this gets back to the optimization of leaving out type info for classes defined in other components.

But I'm new here--I may not know what I'm talking about.

Comment 8 by r...@chromium.org, Sep 1 2016

The __vfptr difference should go away soon. I don't know why nav_controller doesn't have a drop down. That seems like the interesting thing here.

So, the debugger appears to know the name of the type of nav_controller, but it's not connecting it to the complete type definition. It'd be interesting to dump the PDB to confirm that the complete type actually exists.
Components: Build
Status: Untriaged
Summary: Some variables are missing drop-down arrows in MSVC's debugger when building with clang-cl (was: missing debug info in win-clang build, redux)
Ok, retitling this to the dropdown, and filed  bug 643247  for the "Lang" thing.

This bug here seems somewhat important :-)

Comment 11 by r...@chromium.org, Sep 7 2016

Owner: r...@chromium.org
Building unit_tests now, I'll take a look after lunch.

Comment 12 by r...@chromium.org, Sep 7 2016

Why isn't content::NavigationController marked CONTENT_EXPORT? It seems like our solution of checking for dllimport to figure out if the constructor comes from another DLL or not may not actually work.

Comment 13 by r...@chromium.org, Sep 7 2016

Slapping CONTENT_EXPORT on NavigationController fixes the issue, but there are probably more issues like this out there. We should measure how much our debug info size optimizations are saving us, and consider defaulting to -fstandalone-debug with another flag like -flimit-debug-info to enable the current behavior.

Comment 14 by r...@chromium.org, Sep 7 2016

We could also change our heuristic to always emit type information if *any* of the members of the class are dllimport, instead of just looking at the class.

Comment 15 by r...@chromium.org, Sep 12 2016

I implemented c#14 in r281053, which should address the specific issue encountered with content::NavigationController.

---

I also did some experiements with -fstandalone-debug, which completely disable our type info optimizations, and the results are scary. This is the total size of the obj/ directories of a chromium build after building just 'base':
453M    limit/obj
524M    stand/obj

So, turning on -fstandalone-debug generates 17% larger object files, just from extra type information. If I only look at the size of the .debug$T sections on disk, I see we go from 81M to 125M, which is a 35% increase.

Linking base.dll appears to go from 1.625s to 1.750s, but I think that's too short to be a meaningful test. If we wanted to measure the true link time impact, I'd need to experiment with a larger target.

In conclusion, I think we should try to keep -flimit-debug-info on by default. Let's push out r281053 and see if there are still tons more missing type info issues.
Blockedon: 645953
Status: FUntriaged
Status: Fixed
Fixed after https://codereview.chromium.org/2361513002

Sign in to add a comment