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.

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

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.

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.

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.

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

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.
> 

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