[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

Manu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Manu  ---
Seems to be working well!

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #19 from Manu  ---
extern(C++) in D is fraught with perils. When working on a multi-language
program, you really need those symbols and the vtable is super useful to know
everything's in good state.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #18 from Rainer Schuetze  ---
I use the demangler supplied by the debugger with flags as they seem to be used
in C++. That doesn't prepend the module name, though.

But looking at the vtable isn't too common and is probably rather special to
your current work. I also do it sometimes to figure the dynamic type if the
debugger fails to do it.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #17 from Manu  ---
Or if you're looking at a symbol in the watch window let's say, and you step
from D <-> C, and the symbol appears to suddenly change name in the crossing :P

I'm doing a lot of watching vtables as I step back and fourth.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #16 from Manu  ---
Sure, except that it needs to demangle EXACTLY like the MSVC tools, so you
don't see 2 errors from C++ and from D next to eachother and get confused as if
they're different symbols, and then spend minutes figuring out that they're
actually the same symbol, just piped through 2 different demanglers! ;)

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #15 from Rainer Schuetze  ---
demangling C++ is easy, helper functions everywhere... ;-)

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #14 from Manu  ---
I'm noticing C++ symbols in the vtable don't demangle (ie, DMD).
Is there a way to call the C++ demangler that VS uses (to make sure the
demangle is identical)?

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #13 from Manu  ---
Wow! Works on all my tests!

Thanks again!
I wonder if this feature should be turned on by default now :P

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #12 from Rainer Schuetze  ---
Next build also works with /INCREMENTAL.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #11 from Manu  ---
Well this is all great progress.
This experience is starting to feel pretty tight!

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #10 from Rainer Schuetze  ---
Ok, I changed hex values to lower letters.

The order of the class view is

[derived type]
__vfptr
base-types

The base types (multiple with interfaces) are part of the "field list" in the
debug info, so a bit harder to mock fields.

Unfortunately I noticed two more cases where the display fails:

- with interfaces, the vtable contains pointers to thunks, but these have no
symbols attached.
- LDC does not emit any vtable information at all, so nothing to be shown
there.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #9 from Manu  ---
Also, another super-minor detail.
In C++, it shows the derived type member at the top, then __vfptr (ie, first
member), then the normal member listing.

In Mago, it's showing __vfptr at the top, then the derived type member, then
the normal members.
Can we swap those top 2 items to match C++? __vfptr is really just the first
member, and it feels strange when it's disconnected from the other members
(separated by the derived accessor) that way.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #8 from Manu  ---
I just noticed a minor issue...

Mago is displaying hex with A-F in CAPS.
VS debugger displays hex with a-f in lower case.

I'm finding it surprisingly jarring when calling in/out of D, because a pointer
that I was just looking at *looks* different, and I think the value has
changed.
Can we make Mago match VS with lower case hex?

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #7 from Manu  ---
Haha, oh man. Everything is always so hard! ;)

I turned it off and everything works great!

Sadly, /INCREMENTAL is overwhelmingly common, and also the default... basically
nobody will ever turn that off :/

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #6 from Rainer Schuetze  ---
The build was ok, I just looked at the class instance before it was
initialized.

I've now added symbol names (no demangling yet). One gotcha: if you are linking
with /INCREMENTAL, the linker relocates symbols through a series of jumps and
that confuses the symbol display.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #5 from Manu  ---
Even if we can't see the symbol names, seeing the pointers might help matching
values and confirm function order against C++ code that you can also see in the
debugger.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #4 from Rainer Schuetze  ---
It seems I've messed up the defaults between Visual D and mago: you have to
enable it in Tools->Options->Debugger->Mago. I think that being disabled is
actually the better default as the vtable yields no additional information for
most people.

Unfortunately that build is also broken, as it tries to show [0] multiple times
and fails.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #3 from Manu  ---
I just installed that build.
I can see an item in place of the vtable:

-tclass  0x02D2 Source.Base
+[Source.Derived]0x02D2 Source.Derived
 object.Object   D0006: Error: Type resolve failed  
 x   10  int
 y   20  int


It seems there's an object.Object item there, which fails to evaluate
correctly.
It should be void** (or rather, void*[N] to inspect properly) right?

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

--- Comment #2 from Manu  ---
Right, I've noticed that our pointers don't seem to show symbol names like C++
does... why is that? Is that possible to fix?
The experience should match C++.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18846

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
I've implemented this, but allow disabling it with an option on the
Debugger->Mago page. You can try it in
https://ci.appveyor.com/project/rainers/visuald/build/job/sd42f639wlwh77qc/artifacts

It doesn't show symbol names, though, just raw pointer values. I'm not sure
that's good enough.

--