[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