rjmccall added a comment. In D135326#3851678 <https://reviews.llvm.org/D135326#3851678>, @dblaikie wrote:
> In D135326#3851672 <https://reviews.llvm.org/D135326#3851672>, @dblaikie > wrote: > >> (abandoned this, but still kind of curious) >> >> @rjmccall - any background/history of having the CXXABI distinct from the >> OS? I guess the point might've been that the C ABI is part of/the definition >> of the OS, but maybe the CXX ABI is more "floating"/flexible on top of that? >> Though it means these CXX ABIs don't get the benefit of being grouped with >> the rest of the targetOS - instead they're a bunch of switches, which seems >> a bit unfortunate, but I guess there's not lots of properties here, so maybe >> that's OK. > > I guess the other question: Is this flexibility valuable/worthwhile, or could > we fold the CXXABI back into the TargetOS? I don't think we really want to support targeting an OS while independently changing the target C++ ABI, no. But I think "OS implies C++ ABI implies ABI properties" is generally the way people define platforms, and I wouldn't want to create a situation where targets have to manually implement all of the right C++ ABI properties just to get default behavior for a specific C++ ABI or else end up weirdly divergent. If you have a different way to achieve that goal besides composition, that's worth considering. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135326/new/ https://reviews.llvm.org/D135326 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
