On Mon, 18 Nov 2019 11:53:59 +0100 Frederik Seiffert <frede...@algoriddim.com> 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 <thera...@theravensnest.org>: > > > > 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 > >>> > >>> > > > > -- Pirmin Braun p...@pirmin-braun.de +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