[dwarf] Emit all symbols as children of the given module

[ibuclaw]

This allows gdb to correctly build a scope map of all modules, which can be used in conjunction with the D-specific name lookup routines in my fork (works by looking up the current enclosed module, and then seeing if the given name is part of it).

Though perhaps this shouldn't be merged until gdb catches up.
Also, will need to emit struct/class/enum names in the same way.

@MartinNowak - FYI, this implements half of my propsosal (the other half is implementing DW_TAG_imported_declaration)

[MartinNowak]

So you want to parse the human readable function type, e.g. void function() foo(int arg)? Sounds like it would require half of a D parser.

[ibuclaw]

What do you mean?

[MartinNowak]

Doesn't fd->toChars print something like the original function declaration?

[ibuclaw]

Should just be the base identifier name, I've never seen strange things coming from gdc when using this, can check instantiated functions just to be sure though. Why do you think it would require half of a D parser to do it this way though?
If dmd is emitting children correctly in debug, gdb can build up a list of qualified names just by looking up the names of all parents, joining them together using the appropriate separator.

[MartinNowak]

Ah, I confused this with FunctionType::toChars, FuncDeclaration::toChars uses Dsymbol::toChars and should be fine.

[MartinNowak]

This breaks test/runnable/gdb14313.d, and maybe you can come up with some sort of gdb test already.

[ibuclaw]

This breaks test/runnable/gdb14313.d, and maybe you can come up with some sort of gdb test already.

I think it's just a problem with the version of gdb the autotester has installed. Older gdb versions don't know how to correctly handle what I described.

[MartinNowak]

Well, that would mean we break debugging for some user with that gdb version.

[ibuclaw]

If you are using gdb-7.6 or 7.7, you'll have D2 demangling support, in which case getting the value by the full qualified name will match the demangled symbol and start working again.

I don't consider it unreasonable to break older versions of gdb. You for sure cannot use gdb-7.5 with gcc-4.9, for instance.

[MartinNowak]

Well, gdb-7.4 is what you get on Ubuntu 12.04LTS.
http://packages.ubuntu.com/precise/gdb
It would be bad to break already working D debugging. Think of all the disappointed, let-me-tryout-d users.
Do you actually know what the problem is? The failing test already uses qualified but unmangled names (https://github.com/D-Programming-Language/dmd/blob/971b319e45c4e81825265fdb04363806a76bd4a0/test/runnable/gdb14313.d#L9).

[ibuclaw]

Do you actually know what the problem is? The failing test already uses qualified but unmangled names

A mixture between two things:

1. Anything old than gdb-7.8 does not demangle mangled symbols (the demangler has been broken in gdb for a long time)
2. When building up names dynamically by reading dwarf, typenames_concat encounters a namespace-style tag, but knows nothing about how to handle language_d - so it falls back to using :: as a separator.

I think that this PR, and the other two should probably be merged together under one umbrella in a way, as it's looking like the latter two PRs are not trivial (this change just lacks any controls).

But I've still not heard back from anyone who knows better the dmd backend.

FYI gdb-7.10 has been frozen, so I'm going to start submitting a new batch of patches in to further push D support. If you're lucky, you won't notice anything when you switch to gdb-7.11. However, you'll be missing out on quite a lot. :)

[ibuclaw]

My opinion is that the compiler should not be backwards compatible with older debuggers. But no one seems to think that here so in that case debug support will never improve for dmd, alienating most features I have trained gdb to do.

[WalterBright]

It's been a while since 2015. The backwards compatibility issue may no longer be relevant.