www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D Debugger "complaints" (Mago?)

reply Joerg Joergonson <JJoergonson gmail.com> writes:
It is pretty hard to visual D's debugger because it is not very 
helpful.

1. It generally shows memory addresses for objects. Doesn't do me 
much good. Would be nice to first try a toString() or display the 
type name.

2. Objects are not shown as they are but their base class types. 
This tends to leave a lot of info out of the display.

3. Cannot do a refactored type of renaming. Have to use 
search/replace which isn't great.

4. Cannot execute commands in the debugger watch such as 
cast(toChild)x; (see 2)

5. Enums are not shown by name. Do I really have to memorize all 
the values?

6. A lot of junk information that takes up space. e.g., strings 
show "length=0x00000084". would be better to minimize to 84 and 
show by name: e.g., "This is 84 chars long?"(84)

7. Line stepping can be weird because sometimes the current line 
will jump to random places then jump back when stepping again. 
This is probably a bug.


I assume this is due to the mago debugger rather than Visual D 
but not sure(except the renaming ability).
Jun 15 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.06.2016 02:20, Joerg Joergonson wrote:

 It is pretty hard to visual D's debugger because it is not very helpful.

 1. It generally shows memory addresses for objects. Doesn't do me much
 good. Would be nice to first try a toString() or display the type name.



is more common. The C++ debugger never does this as executing code can 
be harmful. I've added showing the derived type as in C++ just a couple 
of days ago.


 2. Objects are not shown as they are but their base class types. This
 tends to leave a lot of info out of the display.


The new version also allows inspecting the derived class.


 3. Cannot do a refactored type of renaming. Have to use search/replace
 which isn't great.


Refactorings are not so easy because it can be harmful if it changes 
things too many places. Fixing "Find all references" would be a first 
step...


 4. Cannot execute commands in the debugger watch such as cast(toChild)x;
 (see 2)


You have to name the type with fully qualified type (e.g. 
"pgk.module.Child") for the cast operation as the debugger has no symbol 
lookup information.


 5. Enums are not shown by name. Do I really have to memorize all the
 values?


This information is not written by the COFF backend of dmd. I need to 
double check with the OMF backend.


 6. A lot of junk information that takes up space. e.g., strings show
 "length=0x00000084". would be better to minimize to 84 and show by name:
 e.g., "This is 84 chars long?"(84)


You get much shorter numbers if you disable hexadecimal display. The 
next version also just prints the string in the "preview" line. To 
actually show length,ptr pair, you can use the raw formatting by 
appending ",!" as with the C++ debugger.


 7. Line stepping can be weird because sometimes the current line will
 jump to random places then jump back when stepping again. This is
 probably a bug.


That's usually due to bad debug information written by dmd (but not 
always). Please file a bug if you have some reproducible test case.


 I assume this is due to the mago debugger rather than Visual D but not
 sure(except the renaming ability).


Yes, mago and dmd involved.
Jun 15 2016
next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:

 [...]



 4. Cannot execute commands in the debugger watch such as 
 cast(toChild)x;


 (see 2)

 You have to name the type with fully qualified type (e.g. 
 "pgk.module.Child") for the cast operation as the debugger has 
 no symbol lookup information.


For very long time I actually thought that this wasn't possible 
with VisualD, until I discovered that I could use the FQ name by 
accident. I think it would be very helpful if the error message 
said "try using the fully qualified name e.g. 
package.module.Type", instead of just "symbol not found".

For me the biggest problem is that its not clearly visible what 
operations are supported by the debugger and I need to figure 
this out by trial and error.

Is possible to include some short documentation that is displayed 
e.g. when the user clicks a "?" button next to the 
minimize/restore/close buttons on the QuickWatch window?
Just a short string listing what is currently supported would be 
a huge improvement in terms of discoverability.

BTW, thank for your work on VisualD and improvements to dmd's 
debug info! It's much appreciated!
Jun 16 2016
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.06.2016 12:04, ZombineDev wrote:

 On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:

 [...]



 4. Cannot execute commands in the debugger watch such as cast(toChild)x;


 (see 2)

 You have to name the type with fully qualified type (e.g.
 "pgk.module.Child") for the cast operation as the debugger has no
 symbol lookup information.


 For very long time I actually thought that this wasn't possible with
 VisualD, until I discovered that I could use the FQ name by accident. I
 think it would be very helpful if the error message said "try using the
 fully qualified name e.g. package.module.Type", instead of just "symbol
 not found".


I agree, the error message could be more helpful. Long term, I'm hoping 
for the D compiler to emit some lookup information. IIRC GDC does this 
already for DWARF debug info.


 For me the biggest problem is that its not clearly visible what
 operations are supported by the debugger and I need to figure this out
 by trial and error.

 Is possible to include some short documentation that is displayed e.g.
 when the user clicks a "?" button next to the minimize/restore/close
 buttons on the QuickWatch window?
 Just a short string listing what is currently supported would be a huge
 improvement in terms of discoverability.


The UI is not really under control of the debug engine, but the 
string-view window could be abused for some help message.


 BTW, thank for your work on VisualD and improvements to dmd's debug
 info! It's much appreciated!


Thanks.
Jun 17 2016
prev sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:

 On 16.06.2016 02:20, Joerg Joergonson wrote:

 It is pretty hard to visual D's debugger because it is not 
 very helpful.

 1. It generally shows memory addresses for objects. Doesn't do 
 me much
 good. Would be nice to first try a toString() or display the 
 type name.



 toString is more common. The C++ debugger never does this as 
 executing code can be harmful. I've added showing the derived 
 type as in C++ just a couple of days ago.


 2. Objects are not shown as they are but their base class 
 types. This
 tends to leave a lot of info out of the display.


 The new version also allows inspecting the derived class.


 3. Cannot do a refactored type of renaming. Have to use 
 search/replace
 which isn't great.


 Refactorings are not so easy because it can be harmful if it 
 changes things too many places. Fixing "Find all references" 
 would be a first step...


 4. Cannot execute commands in the debugger watch such as 
 cast(toChild)x;
 (see 2)


 You have to name the type with fully qualified type (e.g. 
 "pgk.module.Child") for the cast operation as the debugger has 
 no symbol lookup information.


 5. Enums are not shown by name. Do I really have to memorize 
 all the
 values?


 This information is not written by the COFF backend of dmd. I 
 need to double check with the OMF backend.


 6. A lot of junk information that takes up space. e.g., 
 strings show
 "length=0x00000084". would be better to minimize to 84 and 
 show by name:
 e.g., "This is 84 chars long?"(84)


 You get much shorter numbers if you disable hexadecimal 
 display. The next version also just prints the string in the 
 "preview" line. To actually show length,ptr pair, you can use 
 the raw formatting by appending ",!" as with the C++ debugger.


 7. Line stepping can be weird because sometimes the current 
 line will
 jump to random places then jump back when stepping again. This 
 is
 probably a bug.


 That's usually due to bad debug information written by dmd (but 
 not always). Please file a bug if you have some reproducible 
 test case.


 I assume this is due to the mago debugger rather than Visual D 
 but not
 sure(except the renaming ability).


 Yes, mago and dmd involved.


Ok, Thanks. If you could work, at your own pace, at getting mago 
and Visual D up to par with the latest Visual Studio and SDK's I 
would put in some effort in to helping "clean" things up(whatever 

I'm just spoiled or conditioned to it, but I miss that in D.

I'm sure it would be quite easy to add code based debugging 
helpers(sort of like visualizers) to do using D source. To 
prevent "security" issues a warning system could be added easily:

class XXX
{
    string Name;
    version(Debugger_Visualizer)
    {
        string toString() { return x.Name~" is trying to Hack 
you!?"; }
    }

or one could include all that in a separate source like

module Debugger_Visualizers

string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; }
}


Then just keep track of all these cases and make the user sign 
off on(hash the code and use an AA to see if the user has 
previously allowed it).

Other debuggers could eventually take advantage of it too and 
more complex debugging visualizations could be implemented than 
just toStrings (e.g., something similar to std.conv.to).
Jun 16 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.06.2016 04:05, Joerg Joergonson wrote:

 I'm sure it would be quite easy to add code based debugging helpers(sort
 of like visualizers) to do using D source. To prevent "security" issues
 a warning system could be added easily:

 class XXX
 {
    string Name;
    version(Debugger_Visualizer)
    {
        string toString() { return x.Name~" is trying to Hack you!?"; }
    }

 or one could include all that in a separate source like

 module Debugger_Visualizers

 string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; }
 }


 Then just keep track of all these cases and make the user sign off
 on(hash the code and use an AA to see if the user has previously allowed
 it).

 Other debuggers could eventually take advantage of it too and more
 complex debugging visualizations could be implemented than just
 toStrings (e.g., something similar to std.conv.to).


Visualizer code in the binary sounds like an interesting idea. Given 
some convention on naming so that symbols are discoverable and rather 
safe to call, that could be doable.

Mago does not yet support calling code in the debugged process, so that 
would be a first step to implement such kind of visualizers.
Jun 17 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:

 On 17.06.2016 04:05, Joerg Joergonson wrote:

 I'm sure it would be quite easy to add code based debugging 
 helpers(sort
 of like visualizers) to do using D source. To prevent 
 "security" issues
 a warning system could be added easily:

 class XXX
 {
    string Name;
    version(Debugger_Visualizer)
    {
        string toString() { return x.Name~" is trying to Hack 
 you!?"; }
    }

 or one could include all that in a separate source like

 module Debugger_Visualizers

 string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; }
 }


 Then just keep track of all these cases and make the user sign 
 off
 on(hash the code and use an AA to see if the user has 
 previously allowed
 it).

 Other debuggers could eventually take advantage of it too and 
 more
 complex debugging visualizations could be implemented than just
 toStrings (e.g., something similar to std.conv.to).


 Visualizer code in the binary sounds like an interesting idea. 
 Given some convention on naming so that symbols are 
 discoverable and rather safe to call, that could be doable.

 Mago does not yet support calling code in the debugged process, 
 so that would be a first step to implement such kind of 
 visualizers.


It would be interesting, easy on the end user, and "portable" if 
it could be done.  Having it stored in modules could allow 
mago/VD to compile the code(since we know we have the compiler) 
outside the project. Generic debugging helpers could be written 
and shared. It just depends on the difficulty of implementing 
properly ;)
Jun 18 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2016 17:57, Joerg Joergonson wrote:

 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:

 Visualizer code in the binary sounds like an interesting idea. Given
 some convention on naming so that symbols are discoverable and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged process, so
 that would be a first step to implement such kind of visualizers.


 It would be interesting, easy on the end user, and "portable" if it
 could be done.  Having it stored in modules could allow mago/VD to
 compile the code(since we know we have the compiler) outside the
 project. Generic debugging helpers could be written and shared. It just
 depends on the difficulty of implementing properly ;)


Visualizers in a separate module or even binary have the problem of not 
being able to access private symbols. Having it in a DLL built and 
loaded by mago/vd needs an extensive API for reflection and memory 
access. This seems like a larger project...

I'd rather start with some functions in the debuggee itself to be 
searched for the type data to be displayed, e.g.

string mago_visualizer(ref T data);
string mago_visualizer(T)(ref T data);

or some sink-delegate-version to avoid allocations.

mago will try to resolve these for T and its base classes. If it finds 
one, it is called and the string result is displayed.
Jun 19 2016
next sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 On 18.06.2016 17:57, Joerg Joergonson wrote:

 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:

 Visualizer code in the binary sounds like an interesting 
 idea. Given
 some convention on naming so that symbols are discoverable 
 and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged 
 process, so
 that would be a first step to implement such kind of 
 visualizers.


 It would be interesting, easy on the end user, and "portable" 
 if it
 could be done.  Having it stored in modules could allow 
 mago/VD to
 compile the code(since we know we have the compiler) outside 
 the
 project. Generic debugging helpers could be written and 
 shared. It just
 depends on the difficulty of implementing properly ;)


 Visualizers in a separate module or even binary have the 
 problem of not being able to access private symbols. Having it 
 in a DLL built and loaded by mago/vd needs an extensive API for 
 reflection and memory access. This seems like a larger 
 project...

 I'd rather start with some functions in the debuggee itself to 
 be searched for the type data to be displayed, e.g.

 string mago_visualizer(ref T data);
 string mago_visualizer(T)(ref T data);

 or some sink-delegate-version to avoid allocations.

 mago will try to resolve these for T and its base classes. If 
 it finds one, it is called and the string result is displayed.


I have no problem with that, anything that makes life easier is a 
+ for me ;)

A side note, intellisense shows all the possible invocations on a 
type. It would be nice to make a distinction of direct members, 
and such

e.g., a list

Type
method1
field1
...
Base
method1
field1
...
External
....


When looking for a method that I'm not aware of I have to scroll 
through all the module imports(e.g., min, max, Date, abs, 
etc...). If all this stuff was at the button of the list and the 
more relevant stuff was at the top, it would be better. A line 
separator is all that is needed to distinguish.

Basically break the list in to derivation type and sub-sort 
alphabetically rather than using a flat list sorted 
alphabetically.

Probably something quite easy to do? Could be an option.
Jun 21 2016
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.06.2016 00:34, Joerg Joergonson wrote:

 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 On 18.06.2016 17:57, Joerg Joergonson wrote:

 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:

 Visualizer code in the binary sounds like an interesting idea. Given
 some convention on naming so that symbols are discoverable and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged process, so
 that would be a first step to implement such kind of visualizers.


 It would be interesting, easy on the end user, and "portable" if it
 could be done.  Having it stored in modules could allow mago/VD to
 compile the code(since we know we have the compiler) outside the
 project. Generic debugging helpers could be written and shared. It just
 depends on the difficulty of implementing properly ;)


 Visualizers in a separate module or even binary have the problem of
 not being able to access private symbols. Having it in a DLL built and
 loaded by mago/vd needs an extensive API for reflection and memory
 access. This seems like a larger project...

 I'd rather start with some functions in the debuggee itself to be
 searched for the type data to be displayed, e.g.

 string mago_visualizer(ref T data);
 string mago_visualizer(T)(ref T data);

 or some sink-delegate-version to avoid allocations.

 mago will try to resolve these for T and its base classes. If it finds
 one, it is called and the string result is displayed.


 I have no problem with that, anything that makes life easier is a + for
 me ;)

 A side note, intellisense shows all the possible invocations on a type.
 It would be nice to make a distinction of direct members, and such

 e.g., a list

 Type
 method1
 field1
 ...
 Base
 method1
 field1
 ...
 External
 ....


 When looking for a method that I'm not aware of I have to scroll through
 all the module imports(e.g., min, max, Date, abs, etc...). If all this
 stuff was at the button of the list and the more relevant stuff was at
 the top, it would be better. A line separator is all that is needed to
 distinguish.


I guess the less relevant stuff comes from matching UFCS functions with 
broad constraints. You can disable these on the language option page.


 Basically break the list in to derivation type and sub-sort
 alphabetically rather than using a flat list sorted alphabetically.


It can be quite confusing if you are looking for some of the "less 
relevant" functions by typing the first characters, but these don't 
appear due to non-overall sorting. Other suggestions have been to use 
coloring or different fonts.


 Probably something quite easy to do? Could be an option.


Unfortunately, adding something to the UI that is not available by the 
standard control usually means reimplementing the full control.
Jun 22 2016
prev sibling parent reply StarGrazer <Stary Night.com> writes:
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 On 18.06.2016 17:57, Joerg Joergonson wrote:

 [...]


 Visualizers in a separate module or even binary have the 
 problem of not being able to access private symbols. Having it 
 in a DLL built and loaded by mago/vd needs an extensive API for 
 reflection and memory access. This seems like a larger 
 project...

 I'd rather start with some functions in the debuggee itself to 
 be searched for the type data to be displayed, e.g.

 string mago_visualizer(ref T data);
 string mago_visualizer(T)(ref T data);

 or some sink-delegate-version to avoid allocations.

 mago will try to resolve these for T and its base classes. If 
 it finds one, it is called and the string result is displayed.


Has anything like this been added yet?  I would like to be able 
to see the GUID value in the debugger, but it is not showing up...
Mar 22 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.03.2017 22:13, StarGrazer wrote:

 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 On 18.06.2016 17:57, Joerg Joergonson wrote:

 [...]


 Visualizers in a separate module or even binary have the problem of
 not being able to access private symbols. Having it in a DLL built and
 loaded by mago/vd needs an extensive API for reflection and memory
 access. This seems like a larger project...

 I'd rather start with some functions in the debuggee itself to be
 searched for the type data to be displayed, e.g.

 string mago_visualizer(ref T data);
 string mago_visualizer(T)(ref T data);

 or some sink-delegate-version to avoid allocations.

 mago will try to resolve these for T and its base classes. If it finds
 one, it is called and the string result is displayed.


 Has anything like this been added yet?  I would like to be able to see
 the GUID value in the debugger, but it is not showing up...


No, nothing added to that respect. You should be able to view a GUID, 
though. It could be a case of debug info missing from a library (see 
https://issues.dlang.org/show_bug.cgi?id=4014).
Mar 26 2017
parent reply StarGrazer <Stary Night.com> writes:
On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:

 On 22.03.2017 22:13, StarGrazer wrote:

 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 [...]


 Has anything like this been added yet?  I would like to be 
 able to see
 the GUID value in the debugger, but it is not showing up...


 No, nothing added to that respect. You should be able to view a 
 GUID, though. It could be a case of debug info missing from a 
 library (see https://issues.dlang.org/show_bug.cgi?id=4014).


How would I find out? All I know is that GUID and some other 
things show up with as {}, which is very uninformative.
Mar 26 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.03.2017 19:49, StarGrazer wrote:

 On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:

 On 22.03.2017 22:13, StarGrazer wrote:

 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:

 [...]


 Has anything like this been added yet?  I would like to be able to see
 the GUID value in the debugger, but it is not showing up...


 No, nothing added to that respect. You should be able to view a GUID,
 though. It could be a case of debug info missing from a library (see
 https://issues.dlang.org/show_bug.cgi?id=4014).


 How would I find out? All I know is that GUID and some other things show
 up with as {}, which is very uninformative.


Actually, phobos and druntime are built without debug information, and 
dmd does not generate corresponding debug info for code that uses 
structs declared by the libraries.

Even if you rebuild druntime and phobos with debug information, you 
might hit the issue mentioned above. A workaround should be to actually 
reference GUID.init somewhere, as the debug info is only linked in when 
the init property is referred to.

To help with this issue, Visual D has the project option "build and use 
local version of phobos with same compiler options" on the linker page. 
It also allows debugging calls into druntime/phobos.

Unfortunately, this build is broken with recent dmd versions. Currently 
investigating...
Mar 27 2017
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 27.03.2017 18:50, Rainer Schuetze wrote:

 To help with this issue, Visual D has the project option "build and use
 local version of phobos with same compiler options" on the linker page.
 It also allows debugging calls into druntime/phobos.

 Unfortunately, this build is broken with recent dmd versions. Currently
 investigating...


Should be fixed for dmd 2.073 in this build:

https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts

Unfortunately, GUID having an initializer with all zeroes causes all 
references to the init property to be optimized away. The only way I 
found to drag the debug info in is to place this code somewhere at 
global scope.

extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ;
__gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
Mar 27 2017
parent reply StarGrazer <Stary Night.com> writes:
On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:

 On 27.03.2017 18:50, Rainer Schuetze wrote:

 [...]


 Should be fixed for dmd 2.073 in this build:

 https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts

 Unfortunately, GUID having an initializer with all zeroes 
 causes all references to the init property to be optimized 
 away. The only way I found to drag the debug info in is to 
 place this code somewhere at global scope.

 extern extern(C) __gshared int 
 D4core3sys7windows8basetyps4GUID6__initZ;
 __gshared ref_GUID_init = 
 &D4core3sys7windows8basetyps4GUID6__initZ;


None of this worked for me ;/
Mar 27 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 28.03.2017 01:57, StarGrazer wrote:

 On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:

 On 27.03.2017 18:50, Rainer Schuetze wrote:

 [...]


 Should be fixed for dmd 2.073 in this build:

 https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts


 Unfortunately, GUID having an initializer with all zeroes causes all
 references to the init property to be optimized away. The only way I
 found to drag the debug info in is to place this code somewhere at
 global scope.

 extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ;
 __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;


 None of this worked for me ;/


"not working" means it built the "private" phobos library with debug 
information and your code compiled and linked with the above snippet, 
but debug info was still missing?
Apr 01 2017