www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Visual D structs/classes not showing in debugging (reprise)

reply Johnson Jones <JJ Dynomite.com> writes:
Rainer, could you explain to me again why structs and classes are 
not properly shown in the debugger?

The output is always of the form:


eb	{}	gtkc.gdktypes.GdkEventButton

or

e	0x02C4CCF0	gdk.Event.Event

and no fields are ever listed, which makes it extremely useless 
in debugging.

I feel that there really should be no reason it shouldn't be able 
to list them and if I can get visualD to compile I might try 
fixing this since it needs to be done. (debugging in Visual D is 
one of the worse debugging experience I have.. and these 
seemingly minor things are reason...)


If Visual D can't get the info at debug time because it doesn't 
exist(I imagine it does it exist but it's an offshoot of the 
quirkiness of dmd symbols or just a bug in Visual D) then we 
could use json to get the fields and at the very least, list 
them(after all it's still more informative than {} or an address).

Also, if I run it under the visual studio debugger I get

D0006: Error: Type resolve failed

for e. It seems that the issue is really just a bug in visual D 
or from it not implementing something the debugger needs.


If the debugger has the address and knows the structural layout 
it has no issues getting the values. (Although align and order 
may or may not be an issue)

So things should work, there really is no reason why they 
shouldn't except a little elbow grease.


If it is a problem ultimately with dmd, then there should be 
workarounds.


e.g., we could add some hidden functions in to the binary during 
compilation that the debugger could call to get these values.

e.g.,

string DebuggerGetStructValues_gdk_Event_Event(gdk.Event.Event* e)
{
    // extract values of e and put them in json format for 
debugger to use. Most of it is compile time work.
}

Then the debugger just has to call this function internally and 
the values will be put in the string which it can then report to 
the user.

or whatever. There are plenty of ways to build a bridge.
Aug 06 2017
next sibling parent Johnson Jones <JJ Dynomite.com> writes:
"When debugging programs compiled with DMD release 2.049, no 
locals or parameters show up, and evaluating expressions fails. 
The problem is with the linker (v 8.00.7) that comes with that 
release. To fix it, use an updated linker from here: 
http://ftp.digitalmars.com/link.8.00.8.zip. "

from the mago page. Hmm, seems to be related to what I've posted 
before about locals not showing up. I have a later version of the 
linker so maybe there was a regression?
Aug 06 2017
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 06.08.2017 19:03, Johnson Jones wrote:

 Rainer, could you explain to me again why structs and classes are not 
 properly shown in the debugger?


The problem is that the debug information is not included by dmd in the 
final executable if it has been written to a library (as with your gtkd 
library).

This is https://issues.dlang.org/show_bug.cgi?id=4014, which should be 
solved in dmd master. You might want to give the nightly build a try: 
http://nightlies.dlang.org/dmd-nightly/dmd.master.windows.7z

You must add -gf to the "additional command line options" in the project 
configuration.
Aug 06 2017
next sibling parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Sunday, 6 August 2017 at 18:39:42 UTC, Rainer Schuetze wrote:

 On 06.08.2017 19:03, Johnson Jones wrote:

 Rainer, could you explain to me again why structs and classes 
 are not properly shown in the debugger?


 The problem is that the debug information is not included by 
 dmd in the final executable if it has been written to a library 
 (as with your gtkd library).

 This is https://issues.dlang.org/show_bug.cgi?id=4014, which 
 should be solved in dmd master. You might want to give the 
 nightly build a try: 
 http://nightlies.dlang.org/dmd-nightly/dmd.master.windows.7z

 You must add -gf to the "additional command line options" in 
 the project configuration.


Awesome! Seems to work! I owe you a new car!

I still get a few errors

[gdk.Event.Event]	D0006: Error: Type resolve failed	

object Object	D0002: Error: Syntax error	

but other than that I'm seeing stuff, and that is what's 
important. I'll play around with it for a few days and see. It 
it's working like it looks like it's working, it's gonna make 
things a hell of a lot easier.
Aug 06 2017
next sibling parent Johnson Jones <JJ Dynomite.com> writes:
On Sunday, 6 August 2017 at 19:41:52 UTC, FoxyBrown wrote:

 On Sunday, 6 August 2017 at 18:39:42 UTC, Rainer Schuetze wrote:

 On 06.08.2017 19:03, Johnson Jones wrote:

 Rainer, could you explain to me again why structs and classes 
 are not properly shown in the debugger?


 The problem is that the debug information is not included by 
 dmd in the final executable if it has been written to a 
 library (as with your gtkd library).

 This is https://issues.dlang.org/show_bug.cgi?id=4014, which 
 should be solved in dmd master. You might want to give the 
 nightly build a try: 
 http://nightlies.dlang.org/dmd-nightly/dmd.master.windows.7z

 You must add -gf to the "additional command line options" in 
 the project configuration.


 Awesome! Seems to work! I owe you a new car!

 I still get a few errors

 [gdk.Event.Event]	D0006: Error: Type resolve failed	

 object Object	D0002: Error: Syntax error	

 but other than that I'm seeing stuff, and that is what's 
 important. I'll play around with it for a few days and see. It 
 it's working like it looks like it's working, it's gonna make 
 things a hell of a lot easier.


So, some variables are still showing up as {} ;/ I haven't 
investigated enough.

Best I can tell so far is that the ones that are not working are 
gtk objects that are defined in gtk c libs. They exist in gtkD 
but I see a lot of "bgthread-2.0-0.dll'. Module was built without 
symbols."

etc. I'm not sure if that the reason or not. But structs I have 
defined in my modules seem to be showing up fine.
Aug 06 2017
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 06.08.2017 21:41, FoxyBrown wrote:

 [gdk.Event.Event]    D0006: Error: Type resolve failed


This looks like it is showing the derived or the base type. If it is the 
former the name is read from memory and it is possible that is not 
available in the current binary.



 
 object Object    D0002: Error: Syntax error


This looks like you have compiled part of the debug info (e.g. the gtk 
libraries) for the VS debugger (that doesn't like '.' in type names so 
they are replaced with ' '), but use the mago debugger. Please check the 
Compiler->Debug->Debug info option. Unfortunately "suitable for selected 
debug engine" doesn't make sense for libraries, so this should be chosen 
appropriately.

This could also cause the problem above.


 
 but other than that I'm seeing stuff, and that is what's important. I'll 
 play around with it for a few days and see. It it's working like it 
 looks like it's working, it's gonna make things a hell of a lot easier.
Aug 07 2017
prev sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
https://ibb.co/kaJAwa

That shows a screen shot of the behavior. Not sure why some type 
are not showing while others are. They are all from gtkD. Most 
seem to be window.

Looking at window, it looks like the only field defined is

	/** the main Gtk struct */
	protected GdkWindow* gdkWindow;

It would be nice if protected fields were shown.

The real problem is that it looks like getters and setters are 
shown to return the data and, of course Visual D has no way to 
know what is what.

e.g.,

	/** the main Gtk struct as a void* */
	protected override void* getStruct()
	{
		return cast(void*)gdkWindow;
	}


or

	public static GType getType()
	{
		return gdk_window_get_type();
	}


and these are not marked in any way.

I'm not sure what Visual D can do to help this situation.

It's obvious to a human that the above functions are effectively 
wrappers around an internal field.

I'm not sure if Visual D can determine functions that return 
non-void and take 0 args(i.e, getters, specially if their name 
starts with get) and basically treat them as a field and call the 
function to get their value that is inserted in the list as if it 
were a field seamlessly?

If it could, it would at least help fill out the information 
listed a bit rather than show {}. Then we can parse down through 
the data structure and see more of whats going on.


e.g.,

public static string Name() { return "xyc"; }

should ultimately, in the locals/watch/autos, be treated as if it 
were a field of type string with name `Name`. The value, of 
course, can only be gotten by calling the function, which I'm not 
sure if the debugger can do or not while debugging and sitting on 
a BP?(it should, since it should know the address and these 
functions almost surely are safe to call in most cases. If not, 
it just catches the error and displays it. Obviously the function 
could do bad things like write to disk, etc.

Instead, maybe it just list them by name and ignores the value. 
Maybe double clicking on it then could run the function and 
insert the data in to the tree.

Anyways... So close but so far away ;)
Aug 06 2017
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 07.08.2017 04:25, Johnson Jones wrote:

 https://ibb.co/kaJAwa
 
 That shows a screen shot of the behavior. Not sure why some type are not 
 showing while others are. They are all from gtkD. Most seem to be window.
 
 Looking at window, it looks like the only field defined is
 
      /** the main Gtk struct */
      protected GdkWindow* gdkWindow;
 
 It would be nice if protected fields were shown.
 
 The real problem is that it looks like getters and setters are shown to 
 return the data and, of course Visual D has no way to know what is what.
 
 e.g.,
 
      /** the main Gtk struct as a void* */
      protected override void* getStruct()
      {
          return cast(void*)gdkWindow;
      }
 
 
 or
 
      public static GType getType()
      {
          return gdk_window_get_type();
      }
 
 
 and these are not marked in any way.
 
 I'm not sure what Visual D can do to help this situation.


When debugging C++, you can call functions in the watch window. I'm 
hoping this will work for D, too, someday. Unfortunately, it seems with 
the Concord debugger integration it needs a very different approach to 
expression evaluation than what is currently used.

A slight complication is that member functions are never zero argument 
function, because the this pointer has to be passed. So it always needs 
to respect the proper ABI to call a function.


 
 It's obvious to a human that the above functions are effectively 
 wrappers around an internal field.
 
 I'm not sure if Visual D can determine functions that return non-void 
 and take 0 args(i.e, getters, specially if their name starts with get) 
 and basically treat them as a field and call the function to get their 
 value that is inserted in the list as if it were a field seamlessly?


 property functions would be the appropriate members, though that 
attribute is more or less deprecated.


 
 If it could, it would at least help fill out the information listed a 
 bit rather than show {}. Then we can parse down through the data 
 structure and see more of whats going on.
 
 
 e.g.,
 
 public static string Name() { return "xyc"; }
 
 should ultimately, in the locals/watch/autos, be treated as if it were a 
 field of type string with name `Name`.


Not sure why a static function should be considered a field ;)  property 
members would fit in, though.



 The value, of course, can only be 
 gotten by calling the function, which I'm not sure if the debugger can 
 do or not while debugging and sitting on a BP?(it should, since it 
 should know the address and these functions almost surely are safe to 
 call in most cases. If not, it just catches the error and displays it. 
 Obviously the function could do bad things like write to disk, etc.
 
 Instead, maybe it just list them by name and ignores the value. Maybe 
 double clicking on it then could run the function and insert the data in 
 to the tree.
 
 Anyways... So close but so far away ;)
 


See also https://issues.dlang.org/show_bug.cgi?id=16692
Aug 07 2017