Hi,
Neither debugger currently knows anything about the non-fragile ABI.
The Apple runtimes have a few introspection functions that are called
without acquiring the necessary locks, which are intended to be called
by the debugger, but someone needs to write the relevant code in either
gdb or lldb and let me know what hooks they'd like. The lldb code is
relatively approachable and the Objective-C runtime interfaces are quite
well abstracted, so it would be fairly simple to add.
Note that lldb probably does not give you the correct layout, especially
for anything that is not a base class. It looks as if it's relying on
the compiler's guess of where ivars will be, which is not always correct
in the non-fragile ABI.
Materialising ivar offsets is relatively easy. The change is basically
to use a different symbol name for the ivar offsets.
If no one has the time or inclination to do this, then I'd recommend
calling the runtime introspection functions directly from the {g,ll}db
command line. These will give you the correct layouts. It's a little
bit clunky (though would be easy to wrap in a plug-in function), but
these can give you the type and offset of each ivar and let you write
some pointer arithmetic that shows you the correct ivar.
David
On 18/11/2019 09:12, Frederik Seiffert wrote:
Hi Wolfgang,
We’re running into very similar issues debugging using lldb with the GNUstep
Android toolchain, which is using the modern (v2) ABI. Have you been able to
get any further with this?
The following lldb command seems to indicate that the root cause might be lldb
missing knowledge about the ObjC runtime. Could you check if you get the same
output for this?
(lldb) language objc class-table dump
error: current process has no Objective-C runtime loaded
Thanks,
Frederik
Am 18.06.2019 um 02:49 schrieb Wolfgang Lux <wolfgang....@gmail.com>:
Hi all,
has anybody tips for how to debug GNUstep executables built with the
non-fragile ABI?
Gdb seems pretty useless with the non-fragile ABI because all instance variable
offsets appear to be 0 so it's impossible to inspect the contents of any
instances:
(gdb) print *self
$1 = {<> = {isa = 0x6074f8 <_OBJC_CLASS_Test>},
name = 0x6074f8 <_OBJC_CLASS_Test>, value = 0x6074f8 <_OBJC_CLASS_Test>,
parent = 0x6074f8 <_OBJC_CLASS_Test>, children = 0x6074f8 <_OBJC_CLASS_Test>}
I've also tried lldb, which at least understands the object layout:
(lldb) print *self
(Test) $0 = {
NSObject = {
isa = 0x00000000006074f8
}
name = 0x0000000000607588
value = 0x0000000000607588
parent = nil
children = 0x00000000007949b8
}
However, when I try to inspect any of the instance attributes I only get an
error message:
Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol
OBJC_IVAR_$_Test.name
error: The expression could not be prepared to run in the target
(lldb) print self->value
Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol
OBJC_IVAR_$_Test.value
error: The expression could not be prepared to run in the target
I've checked this on Ubuntu 18.04 with lldb 6.0 (and before any FreeBSD
advocates run in, it's exactly the same on FreeBSD 11.3 which comes with lldb
8.0)
All of this works fine on macOS:
(lldb) print *self
(Test) $0 = {
NSObject = {
isa = Test
}
name = 0x0000000100003118 @"$"
value = 0x0000000100003118 @"$"
parent = nil
children = 0x0000000100305910 2 key/value pairs
}
(lldb) print *self->name
(NSString) $1 = {
NSObject = {
isa = __NSCFConstantString
}
}
(lldb) print self->name
(__NSCFConstantString *) $2 = 0x0000000100003118 @"$"
Wolfgang
