[Lldb-commits] [PATCH] D146154: [lldb][gnustep] Add minimal GNUstepObjCRuntime plugin for LanguageTypeObjC on non-Apple platforms

Thu Mar 16 02:22:02 PDT 2023

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