Add support for generating PDB symbols with MinGW clang and lld

[cuavas]

This adds a PDB_SYMBOLS option for builds to generate CodeView PDB debug information alongside executables. It has some limitations:

• It only works when compiling with clang and linking with lld
• It only makes sense for Windows
• It doesn't check to make sure you only use it when it makes sense (it will just fail to compile if you misuse it)
• I'm not particularly proud of how it's integrated, but it seemed like a low-impact way to do it

This allows source-level debugging MinGW builds in WinDbg, with some caveats:

• MAME will throw a fit if you launch it from WinDbg - you need to start it some other way, then attach to it
• Trying to set breakpoints by source line doesn't seem to work, probably because of all the parent directory references in the paths passed to the compiler
• It's a pain to set breakpoints on things in anonymous namespaces because you need to know the generated namespace name

It probably works similarly if you try to debug in Visual Studio, although I haven't tested it (at least not yet).

Anyway, here's a demonstration of attaching to a SOURCES build, setting a breakpoint on a function, triggering a breakpoint, and stepping by line:

I also got rid of two disabled optimisations for SYMBOLS builds:

• We need to force GCC to omit the frame pointer on Windows x86-64 to work around a bug in unwind table generation - in practice this option has no effect
• Disabling tail call optimisation has too much impact on releases

[cuavas]

@galibert, @pmackinlay and/or @MooglyGuy can I get first look opinions on this?

The thing that pushed me over the line to do this was that being effectively unable to debug at all with GDB/lldb on Windows AArch64 is no fun at all, and at least IMO, being able to use WinDbg with some caveats is a lot more useful.

It has a few other potential benefits:

• WinDbg automatically downloads symbols for Windows OS libraries from Microsoft, so you can get half-decent stack traces inside DLLs
• You can build a much bigger subtarget with a detailed symbol level without hitting the PE image size limit when the symbols are in a separate file
• It might be useful for other people who prefer a more graphical debugger than GDB or lldb

[pmackinlay]

I don't have any ARM hardware, but will test this on Windows x86-64 next week and let you know if I find any issues.

clang-cl also generates PDBs that work fine with the Visual Studio debugger, and presumably with WinDbg as well, but again I haven't looked into ARM builds with clang-cl.

[cuavas]

clang-cl is different in other ways, though, e.g. it defaults to the MSVC C++ ABI, uses different command line syntax, etc. The option this adds lets you get a fairly “standard” MAME build (MinGW, Itanium C++ ABI, GNU libstdc++ for the C++ standard library, etc.) that you can debug with Microsoft tools.

[MooglyGuy]

I'll have a look. If this means what I think it means, it should mean being able to run profiles on Intel VTune and AMD μProf without having to compile under Visual Studio. I'll take it for a spin and let you know what shakes loose.

[MooglyGuy]

Seems to work great with AMD μProf.

Excellent work!

[cuavas]

Seems to work great with AMD μProf.

Excellent work!

Cool, I'm glad it helps for a use case I hadn't thought of.

[cuavas]

I’m going to merge this, since:

• It works for other people (not just on my box)
• It seems to be useful for a few use cases
• No-one has objected to the implementation yet