Collateral exceptions seem to be broken

[Rainer Schuetze]

Andrej Mitrovic wrote:
> You mean my build of DMD/Phobos?
> 
> Well the debug symbols are definitely shown after I run cv2pdb on the
> executable (it makes a .pdb file with all the symbols which get loaded
> at runtime by the exe).
> 
> Perhaps displaying names is just unimplemented yet in 2.053 for
> Windows. Using cv2pdb is not a problem for me (and it allows me to use
> VisualD's debugger, which is nice).

It is implemented, but there are currently a few problems:

- the stacktrace uses dbghelp.dll to get symbol information for a code 
address. This often doesn't work with the debug information emitted by
dmd/optlink. You have to convert it with cv2pdb to make it digestable to
dbghelp.

- creating the stack trace uses core.demangle on each symbol, but any 
symbol that cannot be demangled causes exceptions when trying to
demangle it, resulting in recursive attempts to dump the stack. These
symbols include C-style, compressed and "SHA'd" symbols.

- thus, core.demangle should have a simple check to reject any symbol
that does not start with _D<digit>. This does not exclude invalid,
compressed and SHA'd symbols, but it works for most symbols.

- a recent change in dmd causes debug symbols to be written unmangled,
not with mangled names adding all symbols to the list of symbols causing
trouble. This helps debuggers to display sensible names without the need
to be able to demangle names. Additionally, it allows inspecting globals
without knowing the mangled name.
But with this change in place, it is no longer necessary to try
demangling the names. The change might break some tools that rely on 
mangled names, though. Does this raise a red flag for someone?

- cv2pdb demangles names and converts '.' to '@'. The '.' inside symbols
confuses the Microsoft debuggers, e.g. you can no longer inspect the
members of a class instance because of the '.' in the class name.
Unfortunately, the '@' seems to confuse dbghelp.dll, causing it to
output just the part of the symbol until the first '@'. Maybe I should
switch to '_', it even looks better than '@' but it introduces ambiguities.

- it also helps to use a debug build of phobos. Otherwise you won't get 
any symbolic information for phobos-functions on the stack. Missing 
symbols might even cause the stack walker to be unable to unwind the 
proper call stack.
I suggest to even add debug symbols to the release build of phobos, as 
you also don't have debug info for non-template classes and structs 
declared inside phobos, even if your application is built with -g.

Rainer