[clang] [llvm] Add DW_ATE_GNU_complex_signed to fix assertion (PR #161695)

[Orlando Cazalet-Hyams via llvm-commits]

OCHyams wrote:

Thanks for helping dig into the background.

> Oh, llvm-dwarfdump/libDebugInfoDWARF asserts if it doesn't recognize an enumerator in a DWARF enumeration (or specifically in the DW_ATE enumeration)? Yeah, that seems wrong in general - we'll always be behind some other implementations extension usage, etc - and being able to dump unknown stuff is important when investigating bugs, cross-toolchain behavior, etc.

> Ideally, I'd guess - we'd dump what we think the extension name is for an enumerator, and failing that (or perhaps in addition) we might print the absolute number, and something like DW_ATE_lo_user+NNNN to give a sense of where it is in the user extension space)

It's just LLVM CodeGen that asserts, from my little testing I don't think llvm-dwarfdump runs into this issue. Dwarfdump prints the 

> Given that it looks like this use of lo_user wasn't "here's the first extension, and this value has a specific meaning between GCC and Clang" but maybe more "if you see this value, give up on DW_ATE_* and use the name instead" (judging by GCC's use of it for a variety of fallback cases in nearby code, if I'm reading it correctly) - maybe best to not add an explicit name for it, at least not on this basis.

Sounds good. I've changed the assert to ignore the range [lo_user, hi_user], which probably makes sense as LLVM can't discern user-space ATE encoding clashes without extra help?

(llvm-dwarfdump prints the encoding "raw" as 0x80 - see the test)

https://github.com/llvm/llvm-project/pull/161695