slinder1 wrote: > @slinder1 any opinions on this? Would this break any existing AMD tooling > you're aware of?
Nothing I am aware of, and as mentioned it would mean we could replace a hack in rocgdb. > @accauble can you elaborate on "ROCgdb has to use a workaround to detect that > a program is a HIP application". That seems like a reasonable motivation but > can you point us to the place where it does this? ... I have this handy, so I'll just post https://github.com/ROCm/ROCgdb/commit/e1ba71be55ebb0cfaf39fd3a4892e76ca21e840e: ```c++ /* The HIP compiler instead of setting DW_AT_language to DW_LANG_HIP sets it to DW_LANG_C_plus_plus_14. As a workaround for the language detection, we fall back to checking the target architecture when the language is C++. There are still 2 caveats: 1) Erroneously labeling device codes written purely in C++ as HIP 2) Not detecting the host HIP codes as HIP, but the emitted C++14 Point (1) is quite unlikely. Point (2) can be remedied for now with a "set language hip" command in GDB itself. Still, this workaround works better than checking the "producer", since various providers tend to name them slightly differently. */ if (lang == language_cplus && (cu->per_objfile->per_bfd->obfd->arch_info->arch == bfd_arch_amdgcn)) { lang = language_hip; dw_lang = DW_LANG_HIP; } ``` AFAIU LLDB has a similar means to override the language of a CU, so in my opinion we should not gate this change on corresponding support in LLDB. https://github.com/llvm/llvm-project/pull/181738 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
