labath added a comment. Right -- I can understand that. I'm not sure whether this is a real issue -- I'd expect that these compiler-internal symbols would normally have private (not "internal") linkage (and hence be caught by line 330) -- but I'm not insisting on exposing all of the internal linkage symbols either.
However, I think the phrase "meant to be exported" brings us back to the beginning, full circle. Objects with "weak" linkage are also "meant" to be exported (== externally visible in a normal compilation), just like their weak_odr counterparts. I think that the real bug here is that we've started special-casing individual linkage types, and that it's only a matter of time before we find ourselves needing to add another linkage type to this list. Llvm has a bunch of functions to check for the properties of linkage types, and it seems to me like we should be able to pick one of them. So, if we want to just expose the functions that would be visible during a normal compilation, the function to use is `hasLocalLinkage()` (negation of it, that is) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78972/new/ https://reviews.llvm.org/D78972 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
