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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
