Re: Debugging on Linux with non-fragile ABI?

[Pirmin Braun]

On Mon, 18 Nov 2019 11:53:59 +0100
Frederik Seiffert <address@hidden> wrote:

> Hi David,
> 
> Thanks for the info, that’s good to know. Since we require things like ARC 
> and ObjC properties I understand that we need to use a non-fragile ABI, so 
> this leaves us without proper debugging facilities, which is a problem to us 
> and I imagine others as well.
> 
> While we don’t have the expertise to implement this ourselves, we would be 
> willing to sponsor the work to support the non-fragile ABI in both GCC and 
> lldb.

me too

> 
> I understand David is tied up with work, so if anyone on the list would be 
> open to do this I’d appreciate if they could reach out to me. Also please let 
> me know if there is anyone on the GCC or lldb teams I could contact about 
> this.
> 
> Thanks!
> Frederik
> 
> 
> > Am 18.11.2019 um 10:35 schrieb David Chisnall <address@hidden>:
> > 
> > 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 <address@hidden>:
> >>> 
> >>> 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
> >>> 
> >>> 
> > 
> 
> 


-- 
Pirmin Braun address@hidden +49 261 92199400 +49 174 9747584 
Geschäftsführer der Pirmin Braun GmbH www.pirmin-braun.de 
Im Palmenstück 4 - 56072 Koblenz - www.facebook.com/PB.ERP.Software
Registergericht: Koblenz HRB 26312 UStID: DE319238613 Steuernummer: 22/656/03918