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

Adrian Prantl via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Mar 17 14:37:30 PDT 2023


aprantl added a comment.

In D146154#4198730 <https://reviews.llvm.org/D146154#4198730>, @sgraenitz wrote:

> 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'm not sure where eLanguageType being passed in here comes from. Generally for Swift processes with (Apple) Objective-C interoperability enabled, it is the expected case to have both a Swift and an Objective-C runtime in the same process.

>> 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

I think that would be a great way to guard against false positives!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146154/new/

https://reviews.llvm.org/D146154



More information about the lldb-commits mailing list