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


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.


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.

Reply via email to