March 28, 2023

C program:

int notice_me_global = -1;

void main()
{
    notice_me_global = -5;
}

cl app_c.c /DEBUG /Zi /EHsc /std:c11 /link /DEBUG /out:app_c.exe

llvm-pdbutil.exe dump --globals app_c.pdb > dump_c

  688476 | S_GDATA32 [size = 32] `notice_me_global`
           type = 0x0074 (int), addr = 0003:0040

D program:

__gshared int notice_me_global = -1;

extern(C) void main()
{
    notice_me_global = 5;
    int* a;
    *a = 1;
}

dmd -betterC -m64 -g -debug app_d.d

llvm-pdbutil.exe dump --globals app_d.pdb > dump_d

       0 | S_GDATA32 [size = 40] `app_d.notice_me_global`
           type = 0x0074 (int), addr = 0003:3504

Open question:

Why is it:

For D: 0 |
For C: 688476 |

Potential issue:

Debugger doesn't understand: the . in the name app_d.notice_me_global, mangled name also doesn't work

That's the info i provided in the microsoft tracker, maybe some people here can notice something else that's wrong

dump_c: https://gist.github.com/ryuukk/40c6d7d1cd3d6a010242d505380fe233
dump_d: https://gist.github.com/ryuukk/38f43383025907a8f44049503887206c

March 28, 2023

Ready to test folder: https://github.com/microsoft/vscode-cpptools/issues/10751#issuecomment-1486948783

Contains simple source to reproduce the issue + build script

Also contains binaries + dump in case you just want to see the data

Hopefully we can figure that out

March 28, 2023

On Tuesday, 28 March 2023 at 14:02:39 UTC, ryuukk_ wrote:

>

Ready to test folder: https://github.com/microsoft/vscode-cpptools/issues/10751#issuecomment-1486948783

Contains simple source to reproduce the issue + build script

Also contains binaries + dump in case you just want to see the data

Hopefully we can figure that out

I noticed in the pdb, there are no mention of the app_d module

I can only find:

      40 | S_PROCREF [size = 28] `app_d.main`
           module = 1, sum name = 0, offset = 40

and

       0 | S_GDATA32 [size = 40] `app_d.notice_me_global`
           type = 0x0074 (int), addr = 0003:3504

Is that why the debugger can't inspect global variables?

Why doesn't the pdb contain anything about app_d?

March 28, 2023

On linux everything works properly out of the box, i tested with gdb and i can inspect globals

More info + linux dump on my comment: https://github.com/microsoft/vscode-cpptools/issues/10751#issuecomment-1487694435

So it's a problem either with msvc, or the way dmd/ldc write information for the linker?

Anyways..

linux: working out of the box

Windows: poop

Not a good outlook, then we wonder why people move away, debugging is essential

Am i the only want who want to improve things, is it a lost cause?

Should i move on?

March 29, 2023

On 3/28/23 6:42 PM, ryuukk_ wrote:

>

Am i the only want who want to improve things, is it a lost cause?

I'm not one to use a debugger often, but it is very helpful for many people. I lament that the Windows debugging situation out of the box is dreadful. The students I teach D to I don't show the debugger because I'm worried it would confuse them more than help.

I both don't use Windows and mostly do debugging via writeln, so for something that doesn't affect me much, I tend not to put effort in. I'm hoping someone who is motivated enough will do it.

If I recall correctly, visual studio debugging is better than the other solutions. But I don't know having never got debugging to work. I've heard that mago is supposed to work better, and was written for D, but is Visual Studio dependent: https://github.com/rainers/mago

I wonder if there isn't some way to make this work well for other IDEs? I couldn't get it to work on VSCode.

>

Should i move on?

In any case, the debugging experience isn't perfect, but seems like a drastic measure to leave D altogether if you can't debug globals.

-Steve

March 29, 2023

On Wednesday, 29 March 2023 at 15:26:21 UTC, Steven Schveighoffer wrote:

>

On 3/28/23 6:42 PM, ryuukk_ wrote:

>

Am i the only want who want to improve things, is it a lost cause?

I'm not one to use a debugger often, but it is very helpful for many people. I lament that the Windows debugging situation out of the box is dreadful. The students I teach D to I don't show the debugger because I'm worried it would confuse them more than help.

I only use windows because i'm making a game and i have to test on that platform

>

I both don't use Windows and mostly do debugging via writeln, so for something that doesn't affect me much, I tend not to put effort in. I'm hoping someone who is motivated enough will do it.

I am motivated, hopefully someone more knowledgeable can join me figure that out

>

If I recall correctly, visual studio debugging is better than the other solutions. But I don't know having never got debugging to work. I've heard that mago is supposed to work better, and was written for D, but is Visual Studio dependent: https://github.com/rainers/mago

I wonder if there isn't some way to make this work well for other IDEs? I couldn't get it to work on VSCode.

That's unfortunate that the solution is bound to a proprietary editor that requires a license

Effort should be made in the open and be universal, so it's easy to port/adapt to other tools/platforms

Coordinated efforts is the way to go, Go/Rust/Zig people are demonstrating this very well and it helped their growth

> >

Should i move on?

In any case, the debugging experience isn't perfect, but seems like a drastic measure to leave D altogether if you can't debug globals.

-Steve

I exaggerate a little bit i must admit it, but I'm trying to raise awareness, when other languages have no problem with debugging out of the box on popular IDEs, why should it have problems only with D?

Currently, at least on windows, there are 2 problems with debugging:

  • global variables
  • extern(C) variables

I'm willing to find the cause for the 1st one, then i'll attempt the 2nd one, so expect more frustrated posts

I should emphasis again that the reason why i'm into this mess is due to a bug i'm trying to debug related to loading a shared DLL built using DMD on windows, wich apparently is known to be broken for YEARS.. great, more people should voice their complains, D is not a new language..

So what to expect other than frustration? specially when people keep recommending to use "workarounds", well, if the fix is a workaround, one shouldn't be surprised to see people getting frustrated every so often

Also it's more of an accumulation of problems that makes me very annoyed

https://issues.dlang.org/show_bug.cgi?id=20737

This for example shouldn't be a thing in 2023, period

March 30, 2023
On 30/03/2023 10:09 AM, ryuukk_ wrote:
> more people should voice their complains

Making noise about problems in D.learn is not the place to do it, I don't think compiler developers tend to monitor it much.

Show your analysis of the situation in General, that is monitored. Especially since the fix for this stuff is probably pretty simple for TLS.
March 29, 2023

On Wednesday, 29 March 2023 at 21:09:57 UTC, ryuukk_ wrote:

>

Also it's more of an accumulation of problems that makes me very annoyed

https://issues.dlang.org/show_bug.cgi?id=20737

This for example shouldn't be a thing in 2023, period

I agree with you because it's such a simple problem and it's surprising if it exists. I've never used -betterC though, but it's a pity.

SDB@79

1 2 3
Next ›   Last »