aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/dwarf
AgeCommit message (Collapse)Author
2018-09-27cmd/link: move DIE of global variables to their compile unitAlessandro Arzilli
The DIEs for global variables were all assigned to the first emitted compile unit in debug_info, regardless of what it was. Move them instead to their respective compile units. Change-Id: If794fa0ba4702f5b959c6e8c16119b16e7ecf6d8 Reviewed-on: https://go-review.googlesource.com/137235 Reviewed-by: Than McIntosh <thanm@google.com>
2018-07-10cmd/compile: call objabi.PathToPrefix when emitting abstract fnThan McIntosh
When generating an abstract function DIE, call objabi.PathToPrefix on the import path so as to be consistent with how the linker handles import paths. This is intended to resolve another problem with DWARF inline info generation in which there are multiple inconsistent versions of an abstract function DIE for a function whose package path is rewritten/canonicalized by objabi.PathToPrefix. Fixes #26237 Change-Id: I4b64c090ae43a1ad87f47587a1a71f19bc5fc8e8 Reviewed-on: https://go-review.googlesource.com/123036 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-20cmd/ld: link to runtime types from DWARFHeschi Kreinick
Add a new DWARF attribute, DW_AT_go_runtime_type, that gives the offset of the runtime type structure, if any, for a DWARF type. This should allow debuggers to decode interface content without having to do awkward name matching. Fixes #24814 Change-Id: Ic7a66524d2be484154c584afa9697111618efea4 Reviewed-on: https://go-review.googlesource.com/106775 Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: David Chase <drchase@google.com>
2018-04-04cmd/link: process is_stmt data into dwarf line tablesDavid Chase
To improve debugging, instructions should be annotated with DWARF is_stmt. The DWARF default before was is_stmt=1, and to remove "jumpy" stepping the optimizer was tagging instructions with a no-position position, which interferes with the accuracy of profiling information. This allows that to be corrected, and also allows more "jumpy" positions to be annotated with is_stmt=0 (these changes were not made for 1.10 because of worries about further messing up profiling). The is_stmt values are placed in a pc-encoded table and passed through a symbol derived from the name of the function and processed in the linker alongside its processing of each function's pc/line tables. The only change in binary size is in the .debug_line tables measured with "objdump -h --section=.debug_line go1.test" For go1.test, these are 2614 bytes larger, or 0.72% of the size of .debug_line, or 0.025% of the file size. This will increase in proportion to how much the is_stmt flag is used (toggled). Change-Id: Ic1f1aeccff44591ad0494d29e1a0202a3c506a7a Reviewed-on: https://go-review.googlesource.com/93664 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-02cmd/link: fix up debug_range for dsymutil (revert CL 72371)Alessandro Arzilli
Dsymutil, an utility used on macOS when externally linking executables, does not support base address selector entries in debug_ranges. CL 73271 worked around this problem by removing base address selectors and emitting CU-relative relocations for each list entry. This commit, as an optimization, reintroduces the base address selectors and changes the linker to remove them again, but only when it knows that it will have to invoke the external linker on macOS. Compilecmp comparing master with a branch that has scope tracking always enabled: completed 15 of 15, estimated time remaining 0s (eta 2:43PM) name old time/op new time/op delta Template 272ms ± 8% 257ms ± 5% -5.33% (p=0.000 n=15+14) Unicode 124ms ± 7% 122ms ± 5% ~ (p=0.210 n=14+14) GoTypes 873ms ± 3% 870ms ± 5% ~ (p=0.856 n=15+13) Compiler 4.49s ± 2% 4.49s ± 5% ~ (p=0.982 n=14+14) SSA 11.8s ± 4% 11.8s ± 3% ~ (p=0.653 n=15+15) Flate 163ms ± 6% 164ms ± 9% ~ (p=0.914 n=14+15) GoParser 203ms ± 6% 202ms ±10% ~ (p=0.571 n=14+14) Reflect 547ms ± 7% 542ms ± 4% ~ (p=0.914 n=15+14) Tar 244ms ± 7% 237ms ± 3% -2.80% (p=0.002 n=14+13) XML 289ms ± 6% 289ms ± 5% ~ (p=0.839 n=14+14) [Geo mean] 537ms 531ms -1.10% name old user-time/op new user-time/op delta Template 360ms ± 4% 341ms ± 7% -5.16% (p=0.000 n=14+14) Unicode 189ms ±11% 190ms ± 8% ~ (p=0.844 n=15+15) GoTypes 1.13s ± 4% 1.14s ± 7% ~ (p=0.582 n=15+14) Compiler 5.34s ± 2% 5.40s ± 4% +1.19% (p=0.036 n=11+13) SSA 14.7s ± 2% 14.7s ± 3% ~ (p=0.602 n=15+15) Flate 211ms ± 7% 214ms ± 8% ~ (p=0.252 n=14+14) GoParser 267ms ±12% 266ms ± 2% ~ (p=0.837 n=15+11) Reflect 706ms ± 4% 701ms ± 3% ~ (p=0.213 n=14+12) Tar 331ms ± 9% 320ms ± 5% -3.30% (p=0.025 n=15+14) XML 378ms ± 4% 373ms ± 6% ~ (p=0.253 n=14+15) [Geo mean] 704ms 700ms -0.58% name old alloc/op new alloc/op delta Template 38.0MB ± 0% 38.4MB ± 0% +1.12% (p=0.000 n=15+15) Unicode 28.8MB ± 0% 28.8MB ± 0% +0.17% (p=0.000 n=15+15) GoTypes 112MB ± 0% 114MB ± 0% +1.47% (p=0.000 n=15+15) Compiler 465MB ± 0% 473MB ± 0% +1.71% (p=0.000 n=15+15) SSA 1.48GB ± 0% 1.53GB ± 0% +3.07% (p=0.000 n=15+15) Flate 24.3MB ± 0% 24.7MB ± 0% +1.67% (p=0.000 n=15+15) GoParser 30.7MB ± 0% 31.0MB ± 0% +1.15% (p=0.000 n=12+15) Reflect 76.3MB ± 0% 77.1MB ± 0% +0.97% (p=0.000 n=15+15) Tar 39.2MB ± 0% 39.6MB ± 0% +0.91% (p=0.000 n=15+15) XML 41.5MB ± 0% 42.0MB ± 0% +1.29% (p=0.000 n=15+15) [Geo mean] 77.5MB 78.6MB +1.35% name old allocs/op new allocs/op delta Template 385k ± 0% 387k ± 0% +0.51% (p=0.000 n=15+15) Unicode 342k ± 0% 343k ± 0% +0.10% (p=0.000 n=14+15) GoTypes 1.19M ± 0% 1.19M ± 0% +0.62% (p=0.000 n=15+15) Compiler 4.51M ± 0% 4.54M ± 0% +0.50% (p=0.000 n=14+15) SSA 12.2M ± 0% 12.4M ± 0% +1.12% (p=0.000 n=14+15) Flate 234k ± 0% 236k ± 0% +0.60% (p=0.000 n=15+15) GoParser 318k ± 0% 320k ± 0% +0.60% (p=0.000 n=15+15) Reflect 974k ± 0% 977k ± 0% +0.27% (p=0.000 n=15+15) Tar 395k ± 0% 397k ± 0% +0.37% (p=0.000 n=14+15) XML 404k ± 0% 407k ± 0% +0.53% (p=0.000 n=15+15) [Geo mean] 794k 798k +0.52% name old text-bytes new text-bytes delta HelloSize 680kB ± 0% 680kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 9.62kB ± 0% 9.62kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 125kB ± 0% 125kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.11MB ± 0% 1.13MB ± 0% +1.85% (p=0.000 n=15+15) Change-Id: I61c98ba0340cb798034b2bb55e3ab3a58ac1cf23 Reviewed-on: https://go-review.googlesource.com/98075 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-02cmd/compile: optimize scope trackingAlessandro Arzilli
1. Detect and remove the markers of lexical scopes that don't contain any variables early in noder, instead of waiting until the end of DWARF generation. This saves memory by never allocating some of the markers and optimizes some of the algorithms that depend on the number of scopes. 2. Assign scopes to Progs by doing, for each Prog, a binary search over the markers array. This is faster, compared to sorting the Prog list because there are fewer markers than there are Progs. completed 15 of 15, estimated time remaining 0s (eta 2:30PM) name old time/op new time/op delta Template 274ms ± 5% 260ms ± 6% -4.91% (p=0.000 n=15+15) Unicode 126ms ± 5% 127ms ± 9% ~ (p=0.856 n=13+15) GoTypes 861ms ± 5% 857ms ± 4% ~ (p=0.595 n=15+15) Compiler 4.11s ± 4% 4.12s ± 5% ~ (p=1.000 n=15+15) SSA 10.7s ± 2% 10.9s ± 4% +2.01% (p=0.002 n=14+14) Flate 163ms ± 4% 166ms ± 9% ~ (p=0.134 n=14+15) GoParser 203ms ± 4% 205ms ± 6% ~ (p=0.461 n=15+15) Reflect 544ms ± 5% 549ms ± 4% ~ (p=0.174 n=15+15) Tar 249ms ± 9% 245ms ± 6% ~ (p=0.285 n=15+15) XML 286ms ± 4% 291ms ± 5% ~ (p=0.081 n=15+15) [Geo mean] 528ms 529ms +0.14% name old user-time/op new user-time/op delta Template 358ms ± 7% 354ms ± 5% ~ (p=0.242 n=14+15) Unicode 189ms ±11% 191ms ±10% ~ (p=0.438 n=15+15) GoTypes 1.15s ± 4% 1.14s ± 3% ~ (p=0.405 n=15+15) Compiler 5.36s ± 6% 5.35s ± 5% ~ (p=0.588 n=15+15) SSA 14.6s ± 3% 15.0s ± 4% +2.58% (p=0.000 n=15+15) Flate 214ms ±12% 216ms ± 8% ~ (p=0.539 n=15+15) GoParser 267ms ± 6% 270ms ± 5% ~ (p=0.569 n=15+15) Reflect 712ms ± 5% 709ms ± 4% ~ (p=0.894 n=15+15) Tar 329ms ± 8% 330ms ± 5% ~ (p=0.974 n=14+15) XML 371ms ± 3% 381ms ± 5% +2.85% (p=0.002 n=13+15) [Geo mean] 705ms 709ms +0.62% name old alloc/op new alloc/op delta Template 38.0MB ± 0% 38.4MB ± 0% +1.27% (p=0.000 n=15+14) Unicode 28.8MB ± 0% 28.8MB ± 0% +0.16% (p=0.000 n=15+14) GoTypes 112MB ± 0% 114MB ± 0% +1.64% (p=0.000 n=15+15) Compiler 465MB ± 0% 474MB ± 0% +1.91% (p=0.000 n=15+15) SSA 1.48GB ± 0% 1.53GB ± 0% +3.32% (p=0.000 n=15+15) Flate 24.3MB ± 0% 24.8MB ± 0% +1.77% (p=0.000 n=14+15) GoParser 30.7MB ± 0% 31.1MB ± 0% +1.27% (p=0.000 n=15+15) Reflect 76.3MB ± 0% 77.1MB ± 0% +1.03% (p=0.000 n=15+15) Tar 39.2MB ± 0% 39.6MB ± 0% +1.02% (p=0.000 n=13+15) XML 41.5MB ± 0% 42.1MB ± 0% +1.45% (p=0.000 n=15+15) [Geo mean] 77.5MB 78.7MB +1.48% name old allocs/op new allocs/op delta Template 385k ± 0% 387k ± 0% +0.54% (p=0.000 n=15+15) Unicode 342k ± 0% 343k ± 0% +0.10% (p=0.000 n=15+15) GoTypes 1.19M ± 0% 1.19M ± 0% +0.64% (p=0.000 n=14+15) Compiler 4.51M ± 0% 4.54M ± 0% +0.53% (p=0.000 n=15+15) SSA 12.2M ± 0% 12.4M ± 0% +1.16% (p=0.000 n=15+15) Flate 234k ± 0% 236k ± 0% +0.63% (p=0.000 n=14+15) GoParser 318k ± 0% 320k ± 0% +0.63% (p=0.000 n=15+15) Reflect 974k ± 0% 977k ± 0% +0.28% (p=0.000 n=15+15) Tar 395k ± 0% 397k ± 0% +0.38% (p=0.000 n=15+13) XML 404k ± 0% 407k ± 0% +0.55% (p=0.000 n=15+15) [Geo mean] 794k 799k +0.55% name old text-bytes new text-bytes delta HelloSize 680kB ± 0% 680kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 9.62kB ± 0% 9.62kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 125kB ± 0% 125kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.11MB ± 0% 1.12MB ± 0% +1.11% (p=0.000 n=15+15) Change-Id: I95a0173ee28c52be1a4851d2a6e389529e74bf28 Reviewed-on: https://go-review.googlesource.com/95396 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-26cmd: avoid unnecessary type conversionsKunpei Sakai
CL generated mechanically with github.com/mdempsky/unconvert. Also updated cmd/compile/internal/ssa/gen/*.rules manually. Change-Id: If721ef73cf0771ae83ce7e2d11623fc8d9155768 Reviewed-on: https://go-review.googlesource.com/97075 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-02-14cmd/compile: reimplement location list generationHeschi Kreinick
Completely redesign and reimplement location list generation to be more efficient, and hopefully not too hard to understand. RegKills are gone. Instead of using the regalloc's liveness calculations, redo them using the Ops' clobber information. Besides saving a lot of Values, this avoids adding RegKills to blocks that would be empty otherwise, which was messing up optimizations. This does mean that it's much harder to tell whether the generation process is buggy (there's nothing to cross-check it with), and there may be disagreements with GC liveness. But the performance gain is significant, and it's nice not to be messing with earlier compiler phases. The intermediate representations are gone. Instead of producing ssa.BlockDebugs, then dwarf.LocationLists, and then finally real location lists, go directly from the SSA to a (mostly) real location list. Because the SSA analysis happens before assembly, it stores encoded block/value IDs where PCs would normally go. It would be easier to do the SSA analysis after assembly, but I didn't want to retain the SSA just for that. Generation proceeds in two phases: first, it traverses the function in CFG order, storing the state of the block at the beginning and end. End states are used to produce the start states of the successor blocks. In the second phase, it traverses in program text order and produces the location lists. The processing in the second phase is redundant, but much cheaper than storing the intermediate representation. It might be possible to combine the two phases somewhat to take advantage of cases where the CFG matches the block layout, but I haven't tried. Location lists are finalized by adding a base address selection entry, translating each encoded block/value ID to a real PC, and adding the terminating zero entry. This probably won't work on OSX, where dsymutil will choke on the base address selection. I tried emitting CU-relative relocations for each address, and it was *very* bad for performance -- it uses more memory storing all the relocations than it does for the actual location list bytes. I think I'm going to end up synthesizing the relocations in the linker only on OSX, but TBD. TestNexting needs updating: with more optimizations working, the debugger doesn't stop on the continue (line 88) any more, and the test's duplicate suppression kicks in. Also, dx and dy live a little longer now, but they have the correct values. Change-Id: Ie772dfe23a4e389ca573624fac4d05401ae32307 Reviewed-on: https://go-review.googlesource.com/89356 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2018-01-10cmd/compile: workaround for inconsistent receiver param srcposThan McIntosh
Given an inlinable method M in package P: func (r *MyStruct) M(...) { When M is compiled within its home package, the source position that the compiler records for 'r' (receiver parameter variable) is accurate, whereas if M is built as part of the compilation of some other package (body read from export data), the declaration line assigned to 'r' will be the line number of the 'import' directive, not the source line from M's source file. This inconsistency can cause differences in the size of abstract parameter DIEs (due to variable-length encoding), which can then in turn result in bad abstract origin offsets, which in turn triggers build failures on iOS (dsymutil crashes when it encounters an incorrect abstract origin reference). Work around the problem by removing the "declaration line number" attribute within the abstract parameter abbreviation table entry. The decl line attribute doesn't contribute a whole lot to the debugging experience, and it gets rid of the inconsistencies that trigger the dsymutil crashes. Updates #23374. Change-Id: I0fdc8e19a48db0ccd938ceadf85103936f89ce9f Reviewed-on: https://go-review.googlesource.com/87055 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2017-12-15cmd/compile: fixes for bad DWARF abstract origin referencesThan McIntosh
Change the compiler's DWARF inline info generation to be more careful about producing consistent instances of abstract function DIEs. The new strategy is to insure that the only params/variables created in an abstract subprogram DIE are those corresponding to declarations in the original pre-inlining version of the code. If a concrete subprogram winds up with other vars as part of the compilation process (return temps, for example, or scalars generated by splitting a structure into pieces) these are emitted as regular param/variable DIEs instead of concrete DIEs. The linker dwarf test now has a couple of new testpoints that include checks to make sure that all abstract DIE references are sane/resolvable; this will help catch similar problems in the future. Fixes #23046. Change-Id: I9b0030da8673fbb80b7ad50461fcf8c6ac823a37 Reviewed-on: https://go-review.googlesource.com/83675 Run-TryBot: Than McIntosh <thanm@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-11-30compiler,linker: support for DWARF inlined instancesThan McIntosh
Compiler and linker changes to support DWARF inlined instances, see https://go.googlesource.com/proposal/+/HEAD/design/22080-dwarf-inlining.md for design details. This functionality is gated via the cmd/compile option -gendwarfinl=N, where N={0,1,2}, where a value of 0 disables dwarf inline generation, a value of 1 turns on dwarf generation without tracking of formal/local vars from inlined routines, and a value of 2 enables inlines with variable tracking. Updates #22080 Change-Id: I69309b3b815d9fed04aebddc0b8d33d0dbbfad6e Reviewed-on: https://go-review.googlesource.com/75550 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-11-01compile, link: remove base address selector from DWARF range listsAlessandro Arzilli
Dsymutil, an utility used on macOS when externally linking executables, does not support base address selector entries in debug_ranges. To work around this deficiency this commit removes base address selectors from debug_ranges and emits instead a list composed only of compile unit relative addresses. A new type of relocation is introduced, R_ADDRCUOFF, similar to R_ADDROFF, that relocates an address to its offset from the low_pc of the symbol's compile unit. Fixes #21945 Change-Id: Ie991f9bc1afda2b49ac5d734eb41c37d3a37e554 Reviewed-on: https://go-review.googlesource.com/72371 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
2017-10-27cmd/compile, cmd/link: support for DWARF file reference relocationsThan McIntosh
New relocation flavor R_DWARFFILEREF, to be applied to DWARF attribute values that correspond to file references (ex: DW_AT_decl_file, DW_AT_call_file). The LSym for this relocation is the file itself; the linker replaces the relocation target with the index of the specified file in the line table's file section. Note: for testing purposes this patch changes the DWARF function subprogram DIE abbrev to include DW_AT_decl_file (allowed by DWARF but not especially useful) so as to have a way to test this functionality. This attribute will be removed once there are other file reference attributes (coming as part of inlining support). Change-Id: Icf676beb60fcc33f06d78e747ef717532daaa3ba Reviewed-on: https://go-review.googlesource.com/73330 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-10-18cmd/compile, cmd/link: record compiler flags in DW_AT_producerAustin Clements
This adds a whitelisted subset of compiler flags to the DW_AT_producer DWARF attribute of each package compilation unit DIE. This is common practice in DWARF and can help debuggers determine the quality of the produced debugging information. Fixes #22168. Change-Id: I1b994ef2262aa9b88b68eb6e883695d1103acc58 Reviewed-on: https://go-review.googlesource.com/71430 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-10-18cmd/compile: distinguish args and return values in DWARFHeschi Kreinick
Set DW_AT_variable_parameter on DW_TAG_formal_parameters that are actually return values. variable_parameter is supposed to indicate inout parameters, but Go doesn't really have those, and DWARF doesn't have explicit support for multiple return values. This seems to be the best compromise, especially since the implementation of the two is very similar -- both are stack slots. Fixes #21100 Change-Id: Icebabc92b7b397e0aa00a7237478cce84ad1a670 Reviewed-on: https://go-review.googlesource.com/71670 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-10-12cmd/link: generate PC ranges for compilation unit DIEsAustin Clements
When we split separate packages into separate compilation units, we lost PC range information because it was no longer contiguous. This brings it back by constructing proper per-package PC range tables. Change-Id: Id0ab5187e08ac5d13b3d3794977bfc857a56224f Reviewed-on: https://go-review.googlesource.com/69974 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2017-10-12cmd/link: one DWARF compilation unit per packageAustin Clements
Currently, the linker generates one huge DWARF compilation unit for the entire Go binary. This commit creates a separate compilation unit and line table per Go package. We temporarily lose compilation unit PC range information, since it's now discontiguous, so harder to emit. We'll bring it back in the next commit. Beyond being "more traditional", this has various technical advantages: * It should speed up line table lookup, since that requires a sequential scan of the line table. With this change, a debugger can first locate the per-package line table and then scan only that line table. * Once we emit compilation unit PC ranges again, this should also speed up various other debugger reverse PC lookups. * It puts us in a good position to move more DWARF generation into the compiler, which could produce at least the CU header, per-function line table fragments, and per-function frame unwinding info that the linker could simply paste together. * It will let us record a per-package compiler command-line flags (#22168). Change-Id: Ibac642890984636b3ef1d4b37fe97f4453c2cc84 Reviewed-on: https://go-review.googlesource.com/69973 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-05cmd/internal/dwarf: remove unused SymValue methodMatthew Dempsky
Change-Id: Ied42c2778899ce12cc256f0a124b77bf0e141aee Reviewed-on: https://go-review.googlesource.com/68471 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-09-28cmd/compile: cover control flow insns in location listsHeschi Kreinick
The information that's used to generate DWARF location lists is very ssa.Value centric; it uses Values as start and end coordinates to define ranges. That mostly works fine, but control flow instructions don't come from Values, so the ranges couldn't cover them. Control flow instructions are generated when the SSA representation is converted to assembly, so that's the best place to extend the ranges to cover them. (Before that, there's nothing to refer to, and afterward the boundaries between blocks have been lost.) That requires block information in the debugInfo type, which then flows down to make everything else awkward. On the plus side, there's a little less copying slices around than there used to be, so it should be a little faster. Previously, the ranges for empty blocks were not very meaningful. That was fine, because they had no Values to cover, so no debug information was generated for them. But they do have control flow instructions (that's why they exist) and so now it's important that the information be correct. Introduce two sentinel values, BlockStart and BlockEnd, that denote the boundary of a block, even if the block is empty. BlockEnd replaces the previous SurvivedBlock flag. There's one more problem: the last instruction in the function will be a control flow instruction, so any live ranges need to be extended past it. But there's no instruction after it to use as the end of the range. Instead, leave the EndProg field of those ranges as nil and fix it up to point to past the end of the assembled text at the very last moment. Change-Id: I81f884020ff36fd6fe8d7888fc57c99412c4245b Reviewed-on: https://go-review.googlesource.com/63010 Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-09-22cmd/compile,cmd/link: export int global consts to DWARFAlessandro Arzilli
Updates #14517 Change-Id: I23ef88e71c89da12dffcadf5562ea2d7557b62cf Reviewed-on: https://go-review.googlesource.com/61019 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-09-07cmd/compile: revert "more compact representation of DW_AT_high_pc"Heschi Kreinick
This reverts commit 84188296e93dd4d26cb0a75a03a9096794e01e2f AKA CL 60530. Fixes #21783 Change-Id: I68038a77de7446dea68419a40dd25982ea6d7df5 Reviewed-on: https://go-review.googlesource.com/62151 Reviewed-by: Heschi Kreinick <heschi@google.com>
2017-09-06cmd/compile: more compact DWARF location for locals and argumentsAlessandro Arzilli
Now that all functions have a DW_AT_frame_base defined we can use DW_OP_fbreg to specify the location of variables and formal parameters, instead of the DW_OP_call_frame_cfa/DW_OP_consts/DW_OP_plus, saving 2 bytes for every variable and 2 bytes for every formal parameter after the first one. Change-Id: I2c7395b67e4a814a0131ab1520df11ca48ff9327 Reviewed-on: https://go-review.googlesource.com/60550 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2017-09-06cmd/compile: more compact representation of DW_AT_high_pcAlessandro Arzilli
DWARF version 4 allows DW_AT_high_pc to be represented as a constant offset from DW_AT_low_pc, this can help save up to 7 bytes per function/lexical scope. Change-Id: I93638d83638ecad4d0d1bfe27348eae6139820c9 Reviewed-on: https://go-review.googlesource.com/60530 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
2017-08-31cmd/link: emit DW_AT_data_member_location as a constantHeschi Kreinick
Simplify the DWARF representation of structs by emitting field offsets as constants rather than location descriptions. This was not explicitly mentioned as an option in DWARF2. It is mentioned in DWARF4, but isn't listed in the changes, so it's not clear if this was always intended to work or is an undocumented change. Either way, it should be valid DWARF4. Change-Id: Idf7fdd397a21c8f8745673ecc77ef65afa3ffe1c Reviewed-on: https://go-review.googlesource.com/51611 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-08-25cmd/compile: bug fixes for DWARF location listsHeschi Kreinick
Fix two small but serious bugs in the DWARF location list code that should have been caught by the automated tests I didn't write. After emitting debug information for a user variable, mark it as done so that it doesn't get emitted again. Otherwise it would be written once per slot it was decomposed into. Correct a merge error in CL 44350: the location list abbreviations need to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish. Change-Id: I6ab4b8b32b7870981dac80eadf0ebfc4015ccb01 Reviewed-on: https://go-review.googlesource.com/59070 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-08-22cmd/compile: emit DW_AT_decl_lineHeschi Kreinick
Some debuggers use the declaration line to avoid showing variables before they're declared. Emit them for local variables and function parameters. DW_AT_decl_file would be nice too, but since its value is an index into a table built by the linker, that's dramatically harder. In practice, with inlining disabled it's safe to assume that all a function's variables are declared in the same file, so this should still be pretty useful. Change-Id: I8105818c8940cd71bc5473ec98797cce2f3f9872 Reviewed-on: https://go-review.googlesource.com/44350 Reviewed-by: David Chase <drchase@google.com>
2017-08-14cmd/link,compile: Provide size for func typesKeith Randall
They are currently not given a size, which makes the DWARF reader very confused. Particularly things like [4]func() get a size of -4, not 32. Fixes #21097 Change-Id: I01e754134d82fbbe6567e3c7847a4843792a3776 Reviewed-on: https://go-review.googlesource.com/55551 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-07-27[dev.debug] cmd/compile: better DWARF with optimizations onHeschi Kreinick
Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-26[dev.debug] cmd/internal/dwarf: add DWARF abbrevs with location listsHeschi Kreinick
Location lists require new DWARF abbrev entries. Add them before CL 41770 to enable binary comparison. Change-Id: If99461f6896db902f2774e0718065eb3d3522026 Reviewed-on: https://go-review.googlesource.com/50881 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-25[dev.debug] cmd/compile: rename dwarf.Var.Offset to StackOffsetHeschi Kreinick
After we track decomposition, offset could mean stack offset or offset in recomposed variable. Disambiguate. Change-Id: I4d810b8c0dcac7a4ec25ac1e52898f55477025df Reviewed-on: https://go-review.googlesource.com/50875 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-05-26cmd/internal/dwarf: update to DWARF4, emit frame_baseHeschi Kreinick
In preparation for CL 41770, upgrade .debug_info to DWARF4, and emit DW_AT_frame_base on subprograms. This should make no semantic difference. Also fix a long-standing bug/inconsistency in puttattr: it didn't add the addend to ref_addrs. Previously this didn't matter because it was only used for types, but now it's used for section offsets into symbols that have multiple entries. RELNOTE=yes Change-Id: Ib10654ac92edfa29c5167c44133648151d70cf76 Reviewed-on: https://go-review.googlesource.com/44210 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2017-05-18cmd/compile: output DWARF lexical blocks for local variablesAlessandro Arzilli
Change compiler and linker to emit DWARF lexical blocks in .debug_info section when compiling with -N -l. Version of debug_info is updated from DWARF v2 to DWARF v3 since version 2 does not allow lexical blocks with discontinuous PC ranges. Remaining open problems: - scope information is removed from inlined functions - variables records do not have DW_AT_start_scope attributes so a variable will shadow other variables with the same name as soon as its containing scope begins, even before its declaration. Updates #6913. Updates #12899. Change-Id: Idc6808788512ea20e7e45bcf782453acb416fb49 Reviewed-on: https://go-review.googlesource.com/40095 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-05-10cmd/link: include DW_AT_producer in .debug_infoDavid Chase
This can make life easier for Delve (and other debuggers), and can help them with bug reports. Sample producer field (from objdump): <48> DW_AT_producer : Go cmd/compile devel +8a59dbf41a Mon May 8 16:02:44 2017 -0400 Change-Id: I0605843c959b53a60a25a3b870aa8755bf5d5b13 Reviewed-on: https://go-review.googlesource.com/33588 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-04-27dwarf: add marker for embedded fields in dwarfHana Kim
Currently, the following two codes generate the identical dwarf info for type Foo. prog 1) type Foo struct { Bar } prog 2) type Foo struct { Bar Bar } This change adds a go-specific attribute DW_AT_go_embedded_field to annotate each member entry. Its absence or false value indicates the corresponding member is not an embedded field. Update #20037 Change-Id: Ibcbd2714f3e4d97c7b523d7398f29ab2301cc897 Reviewed-on: https://go-review.googlesource.com/41873 Reviewed-by: David Chase <drchase@google.com>
2017-04-07Revert "cmd/compile: output DWARF lexical blocks for local variables"Josh Bleecher Snyder
This reverts commit c8b889cc4824f4dbd64a51a3f7b5b6dce4b87ed2. Reason for revert: broke noopt build, compiler performance regression, new Curfn uses Let's fix those and then try this again. Change-Id: Icc3cad1365d04cac8fd09da9dbb0bbf55c13ef44 Reviewed-on: https://go-review.googlesource.com/39991 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-07cmd/compile: output DWARF lexical blocks for local variablesAlessandro Arzilli
Change compiler and linker to emit DWARF lexical blocks in debug_info. Version of debug_info is updated from DWARF v.2 to DWARF v.3 since version 2 does not allow lexical blocks with discontinuous ranges. Second attempt at https://go-review.googlesource.com/#/c/29591/ Remaining open problems: - scope information is removed from inlined functions - variables in debug_info do not have DW_AT_start_scope attributes so a variable will shadow other variables with the same name as soon as its containing scope begins, before its declaration. Updates golang/go#12899, golang/go#6913 Change-Id: I0e260a45b564d14a87b88974eb16c5387cb410a5 Reviewed-on: https://go-review.googlesource.com/36879 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-03-27cmd/internal/dwarf: remove global encbufJosh Bleecher Snyder
The global encbuf helped avoid allocations. It is incompatible with a concurrent backend. To avoid a performance regression while removing it, introduce two optimizations. First, re-use a buffer in dwarf.PutFunc. Second, avoid a buffer entirely when the int being encoded fits in seven bits, which is about 75% of the time. Passes toolstash-check. Updates #15756 name old alloc/op new alloc/op delta Template 40.6MB ± 0% 40.6MB ± 0% -0.08% (p=0.001 n=8+9) Unicode 29.9MB ± 0% 29.9MB ± 0% ~ (p=0.068 n=8+10) GoTypes 116MB ± 0% 116MB ± 0% +0.05% (p=0.043 n=10+9) SSA 864MB ± 0% 864MB ± 0% +0.01% (p=0.010 n=10+9) Flate 25.8MB ± 0% 25.8MB ± 0% ~ (p=0.353 n=10+10) GoParser 32.2MB ± 0% 32.2MB ± 0% ~ (p=0.353 n=10+10) Reflect 80.2MB ± 0% 80.2MB ± 0% ~ (p=0.165 n=10+10) Tar 27.0MB ± 0% 26.9MB ± 0% ~ (p=0.143 n=10+10) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.400 n=10+9) name old allocs/op new allocs/op delta Template 398k ± 0% 397k ± 0% -0.20% (p=0.002 n=8+9) Unicode 320k ± 0% 321k ± 1% ~ (p=0.122 n=8+10) GoTypes 1.16M ± 0% 1.17M ± 0% ~ (p=0.053 n=10+9) SSA 7.65M ± 0% 7.65M ± 0% ~ (p=0.122 n=10+8) Flate 240k ± 1% 240k ± 1% ~ (p=0.243 n=10+9) GoParser 322k ± 1% 322k ± 1% ~ (p=0.481 n=10+10) Reflect 1.00M ± 0% 1.00M ± 0% ~ (p=0.211 n=9+10) Tar 256k ± 0% 255k ± 1% ~ (p=0.052 n=10+10) XML 400k ± 1% 400k ± 0% ~ (p=0.631 n=10+10) Change-Id: Ia39d9de09232fdbfc9c9cec14587bbf6939c9492 Reviewed-on: https://go-review.googlesource.com/38713 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-03-07cmd/compile/internal/gc: skip autotmp vars in gc againMatthew Dempsky
Instead of skipping them based on string matching much later in the compilation process, skip them up front using the proper API. Passes toolstash-check. Change-Id: Ibd4c0448a0701ba0de3235d4689ef300235fa1d9 Reviewed-on: https://go-review.googlesource.com/37930 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-07cmd/internal/dwarf: use []*Var instead of linked listsMatthew Dempsky
Passes toolstash -cmp. Change-Id: I202b29495ca1aaf3c52879fa99fdc0a4b86703af Reviewed-on: https://go-review.googlesource.com/36419 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-11-16cmd/compile: ensure necessary types appear in .debug_infoDavid Chase
Autotmp filtering was too aggressive and excluded types necessary to make debuggers work properly. Restore the "late filter" in dwarf.go based on names to exclude autotmps, and remove the "early filter" in pgen.go based on how the name was introduced. However, the updated naming scheme with a dot prefix is retained to prevent accidental clashes with legal Go identifier names. Includes test (grouped with runtime gdb tests), verified to fail without the fix. Updates #17644. Fixes #17830. Change-Id: I7ec3f7230083889660236e5f6bc77ba5fe434e93 Reviewed-on: https://go-review.googlesource.com/33233 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-10-31cmd/compile: mark temps with new AutoTemp flag, and use it.David Chase
This is an extension of https://go-review.googlesource.com/c/31662/ to mark all the temporaries, not just the ssa-generated ones. Before-and-after ls -l `go tool -n compile` shows a 3% reduction in size (or rather, a prior 3% inflation for failing to filter temps out properly.) Replaced name-dependent "is it a temp?" tests with calls to *Node.IsAutoTmp(), which depends on AutoTemp. Also replace calls to istemp(n) with n.IsAutoTmp(), to reduce duplication and clean up function name space. Generated temporaries now come with a "." prefix to avoid (apparently harmless) clashes with legal Go variable names. Fixes #17644. Fixes #17240. Change-Id: If1417f29c79a7275d7303ddf859b51472890fd43 Reviewed-on: https://go-review.googlesource.com/32255 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-10-26cmd/compile: avoid truncating fieldname var locationsThan McIntosh
Don't include package path when creating LSyms for auto and param variables during Prog generation, and update the DWARF emit routine accordingly (remove the code that chops off package path from names in DWARF var location expressions). Implementation suggested by mdempsky@. The intent of this change is to have saner location expressions in cases where the variable corresponds to a structure field. For example, the SSA compiler's "decompose" phase can take a slice value and break it apart into three scalar variables corresponding to the fields (slice "X" gets split into "X.len", "X.cap", "X.ptr"). In such cases we want the name in the location expression to omit the package path but preserve the original variable name (e.g. "X"). Fixes #16338 Change-Id: Ibc444e7f3454b70fc500a33f0397e669d127daa1 Reviewed-on: https://go-review.googlesource.com/31819 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-08-18cmd: generate DWARF for functions in compile instead of link.Michael Matloob
This is a copy of golang.org/cl/22092 by Ryan Brown. Here's his original comment: On my machine this increases the average time for 'go build cmd/go' from 2.25s to 2.36s. I tried to measure compile and link separately but saw no significant change. Change-Id: If0d2b756d52a0d30d4eda526929c82794d89dd7b Reviewed-on: https://go-review.googlesource.com/25311 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>