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

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added inline comments.


================
Comment at: lldb/source/Plugins/LanguageRuntime/ObjC/GNUstepObjCRuntime/GNUstepObjCRuntime.cpp:131
+                                        ExecutionContext &exe_ctx) {
+  // TODO: This function is supposed to check whether an ObjC selector is
+  // present for an object. Might be implemented similar as in the Apple V2
----------------
theraven wrote:
> sgraenitz wrote:
> > theraven wrote:
> > > I'm not sure how this is meant to work.  I'd expect this to call one of the runtime's introspection functions.  I believe the Apple version has variants of these that run without acquiring locks, which can be used in the debugger.  We can add these quite easily if necessary.
> > The Apple V2 runtime has two ways to do it: https://github.com/llvm/llvm-project/blob/release/16.x/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp#L1179 I experimented with the one that doesn't require `void *gdb_class_getClass(void*)` from the runtime library, but the JIT kept on crashing. So, for this first version I opted for a minimal implementation that doesn't do any selector checks. Let's look at it in another review.
> Can you open bugs against the runtime for the gdb_* symbols that we need?  I will add them.
> 
> The other method will crash on small objects because they don't have an isa pointer, their isa is in the low 1-3 bits of the object pointer, indexing into a table in the runtime.
Sure https://github.com/gnustep/libobjc2/issues/244


================
Comment at: lldb/test/Shell/Expr/objc-gnustep-print.m:68
+//
+// MEMBERS_OUTSIDE: (lldb) p t->_int
+// MEMBERS_OUTSIDE: (int) $0 = 0
----------------
theraven wrote:
> sgraenitz wrote:
> > theraven wrote:
> > > It's not clear from this test if it's correctly computing the offsets.  I suspect that it isn't, since I don't see any reference to the ivar offset variables.
> > What exactly would you expect to see in the output?
> If the offsets are all wrong, this will still work if it happens to land within zeroed memory, which is quite likely.  It would be good to have a method that set all of the ivars to something and then check for those values explicitly.  Or check for `(char*)t->{ivar} - (char*)t` and make sure that this is the right value (this will change between 32/64/128-bit platforms).
Ok, updated the test. I only checked on 64-bit, but it should support arbitrary pointer widths. Can we skip the test for ivar offset distance? I'd like to avoid testing the actual memory layout here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146154