gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging on Linux with non-fragile ABI?


From: Frederik Seiffert
Subject: Re: Debugging on Linux with non-fragile ABI?
Date: Mon, 18 Nov 2019 11:53:59 +0100

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.

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
>>> 
>>> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]