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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
