cmd/link: enable DWARF on darwin/arm{,64}

[eliasnaur]

DWARF generation is completely disabled on darwin/arm and darwin/arm64. There's a

*ld.FlagW = true // disable DWARF generation

in cmd/link/internal/arm*/obj.go for objabi.Hdarwin. Blindly deleting those lines doesn't result in errors, but doesn't improve Xcode backtrace in my informal crash test.

This issue is about enabling (and testing) DWARF generation on darwin/arm and darwin/arm64 to enjoy the same debugging benefits on iOS as other DWARF-enabled platforms. For example, DWARF probably helps #22716.

[steeve]

Can you output a dwarfdump -a --arch=arm64 of the generated file?

[eliasnaur]

Sure.
dwarfdump-arm64.txt

[steeve]

Looking at it, the data is there, but the values seem... weird:

   CIE_pointer: 0x00000000
    start_addr: 0x0000000000000000 sync/atomic.(*Value).Store
    range_size: 0x00000000000002f0 (end_addr = 0x00000000000002f0)
                DW_CFA_same_value (30)
                DW_CFA_def_cfa_offset_sf (30, 0)
  Instructions: 0x0000000000000000: CFA=31       30=30  31=31
                DW_CFA_advance_loc (20)
                DW_CFA_offset_extended_sf (30, -104)
                DW_CFA_def_cfa_offset_sf (30, 112)
                0x0000000000000014: CFA=31+112   30=[31+8]  31=31+112
                DW_CFA_advance_loc1 (176)
                DW_CFA_same_value (30)
                DW_CFA_def_cfa_offset_sf (30, 0)
                0x00000000000000c4: CFA=31       30=30  31=31
                DW_CFA_advance_loc (4)
                DW_CFA_offset_extended_sf (30, -104)
                DW_CFA_def_cfa_offset_sf (30, 112)
                0x00000000000000c8: CFA=31+112   30=[31+8]  31=31+112

[steeve]

Another instance:

standard_opcode_lengths[ DW_LNS_fixed_advance_pc ] = 1
                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    0 0x00000000 0x00000000 /Users/elias/go/src/golang.org/x/mobile/example/bind/hello/hello.go
file_names[  2]    0 0x00000000 0x00000000 <autogenerated>
0x0000254a: DW_LNE_set_address( 0x0000000000000000 )
0x00002555: DW_LNE_end_sequence
            0x0000000000000000      1      1      0 is_stmt

[steeve]

I'm guessing it was disabled because the generation part is skipped (the 0s indicate default struct values)

[cherrymui]

cmd/go also disables dwarf generation in the compiler:
https://go.googlesource.com/go/+/04a27bef6f2c96251161d63761617542ddc762bc/src/cmd/go/internal/work/gc.go#93

If DWARF works on these platforms, we should also enable the compiler part.

[steeve]

I've tried applying the following diff to Go tip, doing what @cherrymui suggested:

diff --git a/src/cmd/go/internal/work/gc.go b/src/cmd/go/internal/work/gc.go
index 2d61e54333..de474cdef3 100644
--- a/src/cmd/go/internal/work/gc.go
+++ b/src/cmd/go/internal/work/gc.go
@@ -89,7 +89,7 @@ func (gcToolchain) gc(b *Builder, a *Action, archive string, importcfg []byte, a
                gcargs = append(gcargs, "-buildid", a.buildID)
        }
        platform := cfg.Goos + "/" + cfg.Goarch
-       if p.Internal.OmitDebug || platform == "nacl/amd64p32" || platform == "darwin/arm" || platform == "darwin/arm64" || cfg.Goos == "plan9" {
+       if p.Internal.OmitDebug || platform == "nacl/amd64p32" || cfg.Goos == "plan9" {
                gcargs = append(gcargs, "-dwarf=false")
        }
        if strings.HasPrefix(runtimeVersion, "go1") && !strings.Contains(os.Args[0], "go_bootstrap") {
diff --git a/src/cmd/link/internal/arm/obj.go b/src/cmd/link/internal/arm/obj.go
index da16f92345..788be68522 100644
--- a/src/cmd/link/internal/arm/obj.go
+++ b/src/cmd/link/internal/arm/obj.go
@@ -120,7 +120,6 @@ func archinit(ctxt *ld.Link) {
                }

        case objabi.Hdarwin: /* apple MACH */
-               *ld.FlagW = true // disable DWARF generation
                ld.HEADR = ld.INITIAL_MACHO_HEADR
                if *ld.FlagTextAddr == -1 {
                        *ld.FlagTextAddr = 4096 + int64(ld.HEADR)
diff --git a/src/cmd/link/internal/arm64/obj.go b/src/cmd/link/internal/arm64/obj.go
index 6b386ad737..405d22d74f 100644
--- a/src/cmd/link/internal/arm64/obj.go
+++ b/src/cmd/link/internal/arm64/obj.go
@@ -101,7 +101,6 @@ func archinit(ctxt *ld.Link) {
                }

        case objabi.Hdarwin: /* apple MACH */
-               *ld.FlagW = true // disable DWARF generation
                ld.HEADR = ld.INITIAL_MACHO_HEADR
                if *ld.FlagTextAddr == -1 {
                        *ld.FlagTextAddr = 4096 + int64(ld.HEADR)
diff --git a/src/cmd/link/internal/ld/lib.go b/src/cmd/link/internal/ld/lib.go
index 80a7632f64..51d6d64881 100644
--- a/src/cmd/link/internal/ld/lib.go
+++ b/src/cmd/link/internal/ld/lib.go
@@ -566,7 +566,6 @@ func (ctxt *Link) loadlib() {
        // the linker manipulates them, and also symbols whose names
        // would not be shortened by this process.
        if typeSymbolMangling(ctxt) {
-               *FlagW = true // disable DWARF generation
                for _, s := range ctxt.Syms.Allsym {
                        newName := typeSymbolMangle(s.Name)
                        if newName != s.Name {

However, the information, while there, is incomplete, addresses are wrong (they look uninitialized):

----------------------------------------------------------------------
 File: Crash.framework/Crash(go.o) (arm64)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x000206ca  version = 0x0004  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x000206ce)

0x0000000b: TAG_compile_unit [1] *
             AT_name( "sync/atomic" )
             AT_language( DW_LANG_Go )
             AT_stmt_list( 0x00000000 )
             AT_low_pc( 0x0000000000000000 )
             AT_ranges( 0x00000000
                [0x0000000000000000 - 0x0000000000000180)
                 End )
             AT_comp_dir( "." )
             AT_producer( "Go cmd/compile devel +a3df9c4755 Mon Apr 16 21:42:05 2018 +0000; -shared" )

0x00000074:     TAG_subprogram [2] *
                 AT_name( "sync/atomic.(*Value).Store" )
                 AT_low_pc( 0x0000000000000000 )
                 AT_high_pc( 0x0000000000000110 )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "/Users/steeve/go.tip/go/src/sync/atomic/value.go" )
                 AT_external( 0x01 )

[gopherbot]

Change https://golang.org/cl/108295 mentions this issue: cmd/link, cmd/go: enable DWARF on darwin/arm and darwin/arm64

[cherrymui]

Does iOS debugging tools use DWARF? (I'm asking as I don't know why DWARF was disabled on those platforms -- is it because we didn't support it, or because there was no tool use it so no need to do it?)

I tried to enable DWARF on darwin/arm and arm64. I put up a CL https://golang.org/cl/108295. With that CL, it generates DWARF and the DWARF looks reasonable on ARM (32-bit).

$ CGO_ENABLED=1 GOARCH=arm GOARM=7 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go
$ dwarfdump hello
----------------------------------------------------------------------
 File: hello (armv7)
----------------------------------------------------------------------
...
0x000235b7:     TAG_subprogram [2]  
                 AT_name( "main.main" )
                 AT_low_pc( 0x04051d88 )
                 AT_high_pc( 0x04051d8c )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "/private/tmp/hello.go" )
                 AT_external( 0x01 )

0x000235cb:     TAG_subprogram [2]  
                 AT_name( "main.init" )
                 AT_low_pc( 0x04051d98 )
                 AT_high_pc( 0x04051df8 )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "<autogenerated>" )
                 AT_external( 0x01 )
...

But for ARM64, there is some problem. The low PCs for functions look correct (I checked with objdump), but the high PCs don't (e.g. they are even smaller than low PC). There might be other problems, I don't know yet.

$ CGO_ENABLED=1 GOARCH=arm64 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go
$ dwarfdump hello
----------------------------------------------------------------------
 File: hello (arm64)
----------------------------------------------------------------------
...
0x0002874c:     TAG_subprogram [4]  
                 AT_name( "main.main" )
                 AT_low_pc( 0x000000010004b170 )
                 AT_high_pc( 0x00000001000069c8 )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "/private/tmp/hello.go" )
                 AT_external( 0x01 )

0x00028768:     TAG_subprogram [4]  
                 AT_name( "main.init" )
                 AT_low_pc( 0x000000010004b180 )
                 AT_high_pc( 0x0000000100006a18 )
                 AT_frame_base( call-frame-cfa )
                 AT_decl_file( "<autogenerated>" )
                 AT_external( 0x01 )
...

Before I look into the detail, I would want to make sure the DWARF are useful for those platforms.

[steeve]

They are indeed used, Xcode does stack unwinding with them. Without DWARF the stack traces are wrong, then.

On Thu 19 Apr 2018 at 21:13, cherrymui ***@***.***> wrote: Does iOS debugging tools use DWARF? (I'm asking as I don't know why DWARF was disabled on those platforms -- is it because we didn't support it, or because there was no tool use it so no need to do it?) I tried to enable DWARF on darwin/arm and arm64. I put up a CL https://golang.org/cl/108295. With that CL, it generates DWARF and the DWARF looks reasonable on ARM (32-bit). $ CGO_ENABLED=1 GOARCH=arm GOARM=7 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go $ dwarfdump hello ---------------------------------------------------------------------- File: hello (armv7) ---------------------------------------------------------------------- ... 0x000235b7: TAG_subprogram [2] AT_name( "main.main" ) AT_low_pc( 0x04051d88 ) AT_high_pc( 0x04051d8c ) AT_frame_base( call-frame-cfa ) AT_decl_file( "/private/tmp/hello.go" ) AT_external( 0x01 ) 0x000235cb: TAG_subprogram [2] AT_name( "main.init" ) AT_low_pc( 0x04051d98 ) AT_high_pc( 0x04051df8 ) AT_frame_base( call-frame-cfa ) AT_decl_file( "<autogenerated>" ) AT_external( 0x01 ) ... But for ARM64, there is some problem. The low PCs for functions look correct (I checked with objdump), but the high PCs don't (e.g. they are even smaller than low PC). There might be other problems, I don't know yet. $ CGO_ENABLED=1 GOARCH=arm64 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go $ dwarfdump hello ---------------------------------------------------------------------- File: hello (arm64) ---------------------------------------------------------------------- ... 0x0002874c: TAG_subprogram [4] AT_name( "main.main" ) AT_low_pc( 0x000000010004b170 ) AT_high_pc( 0x00000001000069c8 ) AT_frame_base( call-frame-cfa ) AT_decl_file( "/private/tmp/hello.go" ) AT_external( 0x01 ) 0x00028768: TAG_subprogram [4] AT_name( "main.init" ) AT_low_pc( 0x000000010004b180 ) AT_high_pc( 0x0000000100006a18 ) AT_frame_base( call-frame-cfa ) AT_decl_file( "<autogenerated>" ) AT_external( 0x01 ) ... Before I look into the detail, I would want to make sure the DWARF are useful for those platforms. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24883 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIY-wvp2tDTawQdyVQmJvlof7Kzp6Crks5tqOH2gaJpZM4TWYoi> .

-- twitter.com/steeve github.com/steeve linkd.in/smorin

[steeve]

But this is great to see this moving forward! We had hopes with frame pointers, but they turned out not to be used by xcode or libunwind (used by crashlytics, for instance).

On Thu 19 Apr 2018 at 21:24, Steeve Morin ***@***.***> wrote: They are indeed used, Xcode does stack unwinding with them. Without DWARF the stack traces are wrong, then. On Thu 19 Apr 2018 at 21:13, cherrymui ***@***.***> wrote: > Does iOS debugging tools use DWARF? (I'm asking as I don't know why DWARF > was disabled on those platforms -- is it because we didn't support it, or > because there was no tool use it so no need to do it?) > > I tried to enable DWARF on darwin/arm and arm64. I put up a CL > https://golang.org/cl/108295. With that CL, it generates DWARF and the > DWARF looks reasonable on ARM (32-bit). > > $ CGO_ENABLED=1 GOARCH=arm GOARM=7 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go > $ dwarfdump hello > ---------------------------------------------------------------------- > File: hello (armv7) > ---------------------------------------------------------------------- > ... > 0x000235b7: TAG_subprogram [2] > AT_name( "main.main" ) > AT_low_pc( 0x04051d88 ) > AT_high_pc( 0x04051d8c ) > AT_frame_base( call-frame-cfa ) > AT_decl_file( "/private/tmp/hello.go" ) > AT_external( 0x01 ) > > 0x000235cb: TAG_subprogram [2] > AT_name( "main.init" ) > AT_low_pc( 0x04051d98 ) > AT_high_pc( 0x04051df8 ) > AT_frame_base( call-frame-cfa ) > AT_decl_file( "<autogenerated>" ) > AT_external( 0x01 ) > ... > > But for ARM64, there is some problem. The low PCs for functions look > correct (I checked with objdump), but the high PCs don't (e.g. they are > even smaller than low PC). There might be other problems, I don't know yet. > > $ CGO_ENABLED=1 GOARCH=arm64 CC=$HOME/src/go/misc/ios/clangwrap.sh GOOS=darwin go build hello.go > $ dwarfdump hello > ---------------------------------------------------------------------- > File: hello (arm64) > ---------------------------------------------------------------------- > ... > 0x0002874c: TAG_subprogram [4] > AT_name( "main.main" ) > AT_low_pc( 0x000000010004b170 ) > AT_high_pc( 0x00000001000069c8 ) > AT_frame_base( call-frame-cfa ) > AT_decl_file( "/private/tmp/hello.go" ) > AT_external( 0x01 ) > > 0x00028768: TAG_subprogram [4] > AT_name( "main.init" ) > AT_low_pc( 0x000000010004b180 ) > AT_high_pc( 0x0000000100006a18 ) > AT_frame_base( call-frame-cfa ) > AT_decl_file( "<autogenerated>" ) > AT_external( 0x01 ) > ... > > Before I look into the detail, I would want to make sure the DWARF are > useful for those platforms. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#24883 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAIY-wvp2tDTawQdyVQmJvlof7Kzp6Crks5tqOH2gaJpZM4TWYoi> > . > -- twitter.com/steeve github.com/steeve linkd.in/smorin

-- twitter.com/steeve github.com/steeve linkd.in/smorin

[eliasnaur]

With 108295 applied, darwin/arm backtraces looks good now:

Very promising. On darwin/arm64, it is not quite as well:

Both traces are without the arm64 framepointer CL applied.