cmd/link: enable DWARF on darwin/arm{,64} #24883
Comments
|
Can you output a |
|
Sure. |
|
Looking at it, the data is there, but the values seem... weird: |
|
Another instance: |
|
I'm guessing it was disabled because the generation part is skipped (the |
|
cmd/go also disables dwarf generation in the compiler: If DWARF works on these platforms, we should also enable the compiler part. |
andybons
added
OS-Darwin
NeedsFix
|
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): |
|
Change https://golang.org/cl/108295 mentions this issue: |
|
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). 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. Before I look into the detail, I would want to make sure the DWARF are useful for those platforms. |
|
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
|
|
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
|
|
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. |
|
Thanks @eliasnaur! This is great to know. Perhaps we can enable it on ARM32 now (while still investigating ARM64)? Another question is whether we should enable it by default. Does mobile developers care more on binary size or the availability of DWARF? I guess one data point could be what we do for Android. |
|
On further inspection, the darwin/arm and darwin/arm64 are both wrong, but in different ways. The darwin/arm trace is missing the Objective C part of the trace, and the darwin/arm64 is lacking in the Go part. Perhaps there is something about the cgocallback frame on darwin/arm that confuses the unwinder? I think it is useful enough to enable it by default and work out the kinks from there. I believe it is on by default on Android, and you can always strip it again with -ldflags="-w". Both the go and the gomobile command support -ldflags. |
|
@eliasnaur AFAIK stacktraces involving cgo don't work on any architecture. |
|
They do work on darwin/amd64 with the same crash test. |
|
For what it's worth, cgo stack traces work on amd64 GNU/Linux if you import "github.com/ianlancetaylor/cgosymbolizer" (but this is not a supported part of the Go project). |
|
Perhaps we're talking about different kinds of traces? I'm referring to the traces seen in Xcode, not the traces from the Go runtime. |
|
Compiling to c-archives, it seems both AT_low_pc and AT_high_pc are wrong on arm64. For arm: For arm64: Not sure where to go next, though. |
|
Change https://golang.org/cl/108655 mentions this issue: |
|
WIth CL 108655, the addresses from dwarfdump seem correct and stack traces look good in Xcode on darwin/arm64.
|
The workarounds doesn't seem necessary anymore, and blocks DWARF on darwin/arm64. Updates #24883. Change-Id: Ic917c767d3b4f6c51be25566956296f5dd4ead10 Reviewed-on: https://go-review.googlesource.com/108655 TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Cherry Zhang <[email protected]>
|
I'm happy to report that breakpoints work (note the local var |
|
Is the problem with wrong traces in the panic() case iOS specific? It seems to me that it could occur on the desktop platforms as well. If so, feel free to open another issue about that. If the problem covers all platforms it might be fixed quicker. |
|
@eliasnaur indeed I do think this is the same on all platform, will do! |
|
Is all this applicable to gomobile bind? I tried to grab master as of today, which should include both commits mentioned above. I also set *ld.FlagW to false. But a dwarfdump on my .framework gave me nothing. And of course the framework did not get symbolicated upon a crash or a breakpoint. Please advise. Thanks! |
|
It should work, as seen from the discussion. This issue is closed, please open a new one with detailed steps to reproduce the problem. Thanks. If you like, CC me on the issue. |
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.
The text was updated successfully, but these errors were encountered: