Yeah, something about linkage - but that's not the part that's as likely to be a problem as the other part: the other test for C++ language was what causes LLVM to compute the fully qualified name of an entity in the accelerator table ("foo::bar" instead of just "bar" (eg: the bug was things like "std::basic_string<...>::length" showed up in the table as just "length" or "basic_string<...>" without the "std::" prefix, etc)
On Wed, Oct 2, 2019 at 8:48 AM Adrian Prantl <apra...@apple.com> wrote: > > >> On Oct 1, 2019, at 6:40 PM, David Blaikie <dblai...@gmail.com> wrote: > >> > >> This broke gnu_pubnames and other forms of DWARF index of C++ code - > fixed in r373420 (feel free to post-comimt review, etc, of course) > >> > > > > patch for reference: > > > case dwarf::DW_TAG_union_type: > > case dwarf::DW_TAG_enumeration_type: > > return dwarf::PubIndexEntryDescriptor( > > - dwarf::GIEK_TYPE, CU->getLanguage() != > dwarf::DW_LANG_C_plus_plus > > - ? dwarf::GIEL_STATIC > > - : dwarf::GIEL_EXTERNAL); > > + dwarf::GIEK_TYPE, > > + dwarf::isCPlusPlus((dwarf::SourceLanguage)CU->getLanguage()) > > + ? dwarf::GIEL_EXTERNAL > > + : dwarf::GIEL_STATIC); > > case dwarf::DW_TAG_typedef: > > case dwarf::DW_TAG_base_type: > > case dwarf::DW_TAG_subrange_type: > > > On Oct 2, 2019, at 8:32 AM, David Blaikie <dblai...@gmail.com> wrote: > > > > Out of curiosity, should/would this've shown up for you Apple folks too? > (as a failure in the apple/lldb accelerator tables - because the names > would be similarly incorrect) had it just not got to the necessary testing > yet? > > > > +Jonas who knows the accelerator tables better than me. > > It certainly didn't show up in our LLDB bots. I'm not familiar with > GIEL_STATIC vs. GIEL_EXTERNAL; are those linkage specifiers? I don't think > we have an equivalent in the Apple accelerator tables or .debug_names. > > -- adrian
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits