[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging on Linux with non-fragile ABI?
From: |
Pirmin Braun |
Subject: |
Re: Debugging on Linux with non-fragile ABI? |
Date: |
Mon, 18 Nov 2019 13:40:11 +0100 |
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