build: enable frame pointers by default #15840
Comments
|
CL https://golang.org/cl/23451 mentions this issue. |
|
Found OS X problem - alignment in library startup. |
|
Is there any chance to add a flag to turn it off? It's nice and all, but it should be more of a debug option than an always on kinda thing. My two cents. |
|
@OneOfOne Re 'debug option', there are other things we leave on by default because when you need them you really need them, for example the heap profiler or for that matter the garbage collector. It's OK to spend a tiny amount of time making programs easier to write/debug/understand/optimize. That said, yes in the CL, you can turn it off with GOEXPERIMENT=noframepointer. |
|
CL https://golang.org/cl/23458 mentions this issue. |
|
CL https://golang.org/cl/23457 mentions this issue. |
The offsets computed by the DWARF expressions for local variables currently don't account for the extra stack slot used by the frame pointer when GOEXPERIMENT=framepointer is enabled. Fix this by adding the extra stack slot to the offset. This fixes TestGdbPython with GOEXPERIMENT=framepointer. Updates #15840. Change-Id: I1b2ebb2750cd22266f4a89ec8d9e8bfa05fabd19 Reviewed-on: https://go-review.googlesource.com/23458 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
The irregular calling convention for defers currently incorrectly manages the BP if frame pointers are enabled. Specifically, jmpdefer manipulates the SP as if its own caller, deferreturn, had returned. However, it does not manipulate the BP to match. As a result, when a BP-based traceback happens during a deferred function call, it unwinds to the function that performed the defer and then thinks that function called itself in an infinite regress. Fix this by making jmpdefer manipulate the BP as if deferreturn had actually returned. Fixes #12968. Updates #15840. Change-Id: Ic9cc7c863baeaf977883ed0c25a7e80e592cf066 Reviewed-on: https://go-review.googlesource.com/23457 Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
|
@rsc thank you for enabling frame pointers, I've been using perf all morning and it's wonderful to have real backtraces. |
For #15840. Change-Id: I2ecf5c7b00afc2034cf3d7a1fd78636a908beb67 Reviewed-on: https://go-review.googlesource.com/23517 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
We plan to make GOEXPERIMENT=framepointer the default for the Go 1.7 beta 1,
as a trial balloon toward leaving it on for the Go 1.7 release.
There is a small performance hit to having frame pointers enabled
(typically 1-3%), but this release brings with it significantly more
than that due to SSA, so we have the budget available to do this without
slowing down user programs compared to the previous release.
Having frame pointers on by default means that Linux perf, Intel VTune,
and other profilers can grab Go stack traces much more efficiently,
making the profiles significantly more reflective of reality.
This is a good default to have. The performance work enabled by this
probably also significantly outweighs the slowdown.
/cc @aclements @randall77
The text was updated successfully, but these errors were encountered: