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.

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.

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.

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

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!