www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Global variables not accessible with Visual Studio debugger

reply pdgr <pdgr foo.bar> writes:
Hello,

I have a program that I want to debug on Windows 10 using Visual 
Studio 2022. I'm debugging the built .exe directly (not using 
VisualD or anything).

The program is compiled with dmd ver v2.099.0 using the following 
flags:
   dmd main.d -debug -g -gf -gs -m64

In Visual Studio when I type the name of my global variable in 
the watch window it can't find it.. any way to solve this? I 
found some old thread that suggested using 
{module-name}.{global-var-name} but that doesn't work either.

Thanks in advance.
Apr 21 2022
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 21/04/2022 21:37, pdgr wrote:
 Hello,
 
 I have a program that I want to debug on Windows 10 using Visual Studio 
 2022. I'm debugging the built .exe directly (not using VisualD or 
 anything).
Without Visual D (or to be more precise: without the mago debugger extension that comes with Visual D), you are rather limited when debugging D code.
 
 The program is compiled with dmd ver v2.099.0 using the following flags:
    dmd main.d -debug -g -gf -gs -m64
 
 In Visual Studio when I type the name of my global variable in the watch 
 window it can't find it.. any way to solve this? I found some old thread 
 that suggested using {module-name}.{global-var-name} but that doesn't 
 work either.
 
It might work to use the mangled name, e.g. _D3mod4namei. You can find the exact speelling in the disassembly of an access to the variable. An alternative might be to use extern(C) when declaring the variable.
Apr 23 2022
parent reply pdgr <pdgr foo.bar> writes:
Thanks for the suggestions, the extern(C) thing doesn't work.. 
but in the disassembly I can see the mangled name and I can 
inspect the value in the watch window using that mangled name. 
Kinda annoying but it works.
Apr 23 2022
parent reply pdgr <pdgr foo.bar> writes:
On Saturday, 23 April 2022 at 13:29:16 UTC, pdgr wrote:
 Thanks for the suggestions, the extern(C) thing doesn't work.. 
 but in the disassembly I can see the mangled name and I can 
 inspect the value in the watch window using that mangled name. 
 Kinda annoying but it works.
Scratch that.. it doesn't actually work: the disassembly doesn't not contain any mangled names, I mistook a hex value for the mangled name.
Apr 23 2022
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 23/04/2022 15:41, pdgr wrote:
 On Saturday, 23 April 2022 at 13:29:16 UTC, pdgr wrote:
 Thanks for the suggestions, the extern(C) thing doesn't work.. but in 
 the disassembly I can see the mangled name and I can inspect the value 
 in the watch window using that mangled name. Kinda annoying but it works.
Scratch that.. it doesn't actually work: the disassembly doesn't not contain any mangled names, I mistook a hex value for the mangled name.
I suspect you are trying to watch a thread local variable that uses indirect addressing. With shared or __gshared variables, you see the symbol being used as debug information, but the debugger cannot handle that as a C++ expression. You can see the mangled symbol with "pragma(msg, var.mangleof)" at compile time. Using this in the watch window shows it as a "void*", which you can then cast to your type using C++-Syntax, e.g. "*(int*)_D3mod3tlsi". I'd recommend installing Visual D including the debugger extension mago instead, though ;-)
Apr 23 2022
parent pdgr <pdgr foo.bar> writes:
On Sunday, 24 April 2022 at 06:11:03 UTC, Rainer Schuetze wrote:
 On 23/04/2022 15:41, pdgr wrote:
 On Saturday, 23 April 2022 at 13:29:16 UTC, pdgr wrote:
 Thanks for the suggestions, the extern(C) thing doesn't 
 work.. but in the disassembly I can see the mangled name and 
 I can inspect the value in the watch window using that 
 mangled name. Kinda annoying but it works.
Scratch that.. it doesn't actually work: the disassembly doesn't not contain any mangled names, I mistook a hex value for the mangled name.
I suspect you are trying to watch a thread local variable that uses indirect addressing. With shared or __gshared variables, you see the symbol being used as debug information, but the debugger cannot handle that as a C++ expression. You can see the mangled symbol with "pragma(msg, var.mangleof)" at compile time. Using this in the watch window shows it as a "void*", which you can then cast to your type using C++-Syntax, e.g. "*(int*)_D3mod3tlsi". I'd recommend installing Visual D including the debugger extension mago instead, though ;-)
Ok thanks for the help!
Apr 24 2022