(Note to self https://bugs.chromium.org/p/chromium/issues/detail?id=636099 too.)

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.

Deleted: cl.png 424 KB

	cl.png 424 KB View Download

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)?

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.

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.

Ok, retitling this to the dropdown, and filed  bug 643247  for the "Lang" thing.

This bug here seems somewhat important :-)

Building unit_tests now, I'll take a look after lunch.

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.

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.

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.

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.

Fixed after https://codereview.chromium.org/2361513002