sgraenitz marked 3 inline comments as done. sgraenitz added a comment. In D146154#4197454 <https://reviews.llvm.org/D146154#4197454>, @aprantl wrote:
> One thing I just realized — we need to make sure that we don't accidentally > create a GNUstep ObjC runtime in a Swift process that was built without ObjC > support on Linux. Yes, thanks for bringing this up. The goal definitely is to avoid any accidental conflicts with existing use cases that don't need or expect a GNUstep runtime. I really want to get my focus to the Windows side and PDB parsing. It's useful to have Linux working as well, so that we have a testable feature set to match. Otherwise, we don't want to invest a lot of effort here yet. > How can we ensure this works for both cases? Shouldn't the Swift processes report `eLanguageTypeSwift`? Then `GNUstepObjCRuntime::CreateInstance()` rejects it reliably. > I.e., can you detect based on the presence of a symbol or shared object that > an GNUstep runtime is present? Are there existing cases that follow such an approach? Looking at the order of events here, it appears that we have to wait for `ModulesDidLoad()` to report the shared library before we can inspect its symbols. How would we proceed if we want to create the language runtime first? I.e. here https://github.com/llvm/llvm-project/blob/release/16.x/lldb/source/Target/Process.cpp#L5727-L5732 The shared library has a GNUstep-specific EH personality for example, would that do? > llvm-nm libobjc2/build/libobjc.so | grep gnustep_objc 00000000000264c0 T __gnustep_objc_personality_v0 0000000000026500 T __gnustep_objcxx_personality_v0 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146154/new/ https://reviews.llvm.org/D146154 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
