In DMD, put a breakpoint somewhere at the top of mars.d: tryMain()
This function refers to `global` frequently, eg `global.params`, `global.inifilename`, etc.
Notice that the debuginfo seems to be missing for `global`, the debugger just says "Symbol not found", and you can't inspect the members.
I've seen this problem a lot, but this is a very convenient repro in a popular codebase :)
Comment #1 by turkeyman — 2018-05-20T02:08:01Z
Perhaps it's the extern(C++) that's the problem?
That would explain why I have debug problems a lot.
Comment #2 by r.sagitario — 2018-05-20T06:27:41Z
See also issue 11024: there is no information about imports in the debug informations so you don't know which symbols are visible in the current scope and what their qualified name is.
In D functions, the qualified name is used to find the requested symbol, too. This fails for extern(C/C++) functions that don't have the qualification, or if the symbol is in another module.
You can still watch the variable using the fully qualified name (even for extern(C++) symbols), e.g. "dmd.globals.global". This actually matches C++ symbols that are in namespaces which also have to be specified.
Comment #3 by turkeyman — 2018-05-20T06:55:27Z
Hmm... yeah, that's unfortunate.
I don't understand why it's hard to resolve the name. It's extern(C++), and it has no namespace supplied, so the correct symbol name should just be the mangled name, with no scope or anything.
How is it that qualified names (with the D scope) can find a C++ symbol? The C++ symbol has no concept of D scope. Why does it need to be given a scope at all?
Comment #4 by r.sagitario — 2018-05-20T07:02:26Z
The debug info contains the "pretty" name, i.e. the fully qualified name, even for extern(C++) symbols. Otherwise you would have to guess the linkage and type as it is part of the mangled name.
What could be possible is to inspect all symbol at startup and create a map using the unqualified name as key. That might have a number of conflicts, though.