An error occurred fetching the project authors.
  1. 11 Feb, 2015 1 commit
  2. 03 Feb, 2015 1 commit
  3. 30 Jan, 2015 1 commit
  4. 26 Jan, 2015 1 commit
    • Russ Cox's avatar
      cmd/gc: simplify code for c2go · e82003e7
      Russ Cox authored
      - Change forward reference to struct Node* to void* in liblink.
      - Use explicit (Node*) casts in cmd/gc to get at that field.
      - Define struct Array in go.h instead of hiding it in array.c.
      - Remove some sizeof(uint32), sizeof(uint64) uses.
      - Remove some ? : expressions.
      - Rewrite some problematic mid-expression assignments.
      
      Change-Id: I308c70140238a0cfffd90e133f86f442cd0e17d4
      Reviewed-on: https://go-review.googlesource.com/3276Reviewed-by: default avatarRob Pike <r@golang.org>
      e82003e7
  5. 23 Dec, 2014 1 commit
  6. 15 Oct, 2014 1 commit
    • Russ Cox's avatar
      cmd/gc: simplify compiled code for explicit zeroing · 3c40ee0f
      Russ Cox authored
      Among other things, *x = T{} does not need a write barrier.
      The changes here avoid an unnecessary copy even when
      no pointers are involved, so it may have larger effects.
      
      In 6g and 8g, avoid manually repeated STOSQ in favor of
      writing explicit MOVs, under the theory that the MOVs
      should have fewer dependencies and pipeline better.
      
      Benchmarks compare best of 5 on a 2012 MacBook Pro Core i5
      with TurboBoost disabled. Most improvements can be explained
      by the changes in this CL.
      
      The effect in Revcomp is real but harder to explain: none of
      the instructions in the inner loop changed. I suspect loop
      alignment but really have no idea.
      
      benchmark                       old         new         delta
      BenchmarkBinaryTree17           3809027371  3819907076  +0.29%
      BenchmarkFannkuch11             3607547556  3686983012  +2.20%
      BenchmarkFmtFprintfEmpty        118         103         -12.71%
      BenchmarkFmtFprintfString       289         277         -4.15%
      BenchmarkFmtFprintfInt          304         290         -4.61%
      BenchmarkFmtFprintfIntInt       507         458         -9.66%
      BenchmarkFmtFprintfPrefixedInt  425         408         -4.00%
      BenchmarkFmtFprintfFloat        555         555         +0.00%
      BenchmarkFmtManyArgs            1835        1733        -5.56%
      BenchmarkGobDecode              14738209    14639331    -0.67%
      BenchmarkGobEncode              14239039    13703571    -3.76%
      BenchmarkGzip                   538211054   538701315   +0.09%
      BenchmarkGunzip                 135430877   134818459   -0.45%
      BenchmarkHTTPClientServer       116488      116618      +0.11%
      BenchmarkJSONEncode             28923406    29294334    +1.28%
      BenchmarkJSONDecode             105779820   104289543   -1.41%
      BenchmarkMandelbrot200          5791758     5771964     -0.34%
      BenchmarkGoParse                5376642     5310943     -1.22%
      BenchmarkRegexpMatchEasy0_32    195         190         -2.56%
      BenchmarkRegexpMatchEasy0_1K    477         455         -4.61%
      BenchmarkRegexpMatchEasy1_32    170         165         -2.94%
      BenchmarkRegexpMatchEasy1_1K    1410        1394        -1.13%
      BenchmarkRegexpMatchMedium_32   336         329         -2.08%
      BenchmarkRegexpMatchMedium_1K   108979      106328      -2.43%
      BenchmarkRegexpMatchHard_32     5854        5821        -0.56%
      BenchmarkRegexpMatchHard_1K     185089      182838      -1.22%
      BenchmarkRevcomp                834920364   780202624   -6.55%
      BenchmarkTemplate               137046937   129728756   -5.34%
      BenchmarkTimeParse              600         594         -1.00%
      BenchmarkTimeFormat             559         539         -3.58%
      
      LGTM=r
      R=r
      CC=golang-codereviews, iant, khr, rlh
      https://golang.org/cl/157910047
      3c40ee0f
  7. 12 Sep, 2014 2 commits
  8. 08 Sep, 2014 1 commit
    • Russ Cox's avatar
      build: adjustments for move from src/pkg to src · 220a6de4
      Russ Cox authored
      This CL adjusts code referring to src/pkg to refer to src.
      
      Immediately after submitting this CL, I will submit
      a change doing 'hg mv src/pkg/* src'.
      That change will be too large to review with Rietveld
      but will contain only the 'hg mv'.
      
      This CL will break the build.
      The followup 'hg mv' will fix it.
      
      For more about the move, see golang.org/s/go14nopkg.
      
      LGTM=r
      R=r
      CC=golang-codereviews
      https://golang.org/cl/134570043
      220a6de4
  9. 11 Aug, 2014 1 commit
  10. 04 Apr, 2014 1 commit
  11. 02 Apr, 2014 5 commits
    • David du Colombier's avatar
      cmd/8g, cmd/gc: fix warnings on Plan 9 · 9f9c9abb
      David du Colombier authored
      warning: src/cmd/8g/ggen.c:35 non-interruptable temporary
      warning: src/cmd/gc/walk.c:656 set and not used: l
      warning: src/cmd/gc/walk.c:658 set and not used: l
      
      LGTM=minux.ma
      R=golang-codereviews, minux.ma
      CC=golang-codereviews
      https://golang.org/cl/83660043
      9f9c9abb
    • Keith Randall's avatar
      cmd/gc: Don't zero more than we need. · 47acf167
      Keith Randall authored
      Don't merge with the zero range, we may
      end up zeroing more than we need.
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/83430044
      47acf167
    • Keith Randall's avatar
      runtime: zero at start of frame more efficiently. · 383963b5
      Keith Randall authored
      Use Duff's device for zeroing.  Combine adjacent regions.
      
      Update #7680
      Update #7624
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/83200045
      383963b5
    • Russ Cox's avatar
      cmd/5g, cmd/8g: fix build · 9c8f11ff
      Russ Cox authored
      Botched during CL 83090046.
      
      TBR=khr
      CC=golang-codereviews
      https://golang.org/cl/83070046
      9c8f11ff
    • Russ Cox's avatar
      cmd/gc: shorten more temporary lifetimes · daca06f2
      Russ Cox authored
      1. In functions with heap-allocated result variables or with
      defer statements, the return sequence requires more than
      just a single RET instruction. There is an optimization that
      arranges for all returns to jump to a single copy of the return
      epilogue in this case. Unfortunately, that optimization is
      fundamentally incompatible with PC-based liveness information:
      it takes PCs at many different points in the function and makes
      them all land at one PC, making the combined liveness information
      at that target PC a mess. Disable this optimization, so that each
      return site gets its own copy of the 'call deferreturn' and the
      copying of result variables back from the heap.
      This removes quite a few spurious 'ambiguously live' variables.
      
      2. Let orderexpr allocate temporaries that are passed by address
      to a function call and then die on return, so that we can arrange
      an appropriate VARKILL.
      
      2a. Do this for ... slices.
      
      2b. Do this for closure structs.
      
      2c. Do this for runtime.concatstring, which is the implementation
      of large string additions. Change representation of OADDSTR to
      an explicit list in typecheck to avoid reconstructing list in both
      walk and order.
      
      3. Let orderexpr allocate the temporary variable copies used for
      range loops, so that they can be killed when the loop is over.
      Similarly, let it allocate the temporary holding the map iterator.
      
      CL 81940043 reduced the number of ambiguously live temps
      in the godoc binary from 860 to 711.
      
      This CL reduces the number to 121. Still more to do, but another
      good checkpoint.
      
      Update #7345
      
      LGTM=khr
      R=khr
      CC=golang-codereviews
      https://golang.org/cl/83090046
      daca06f2
  12. 01 Apr, 2014 2 commits
    • Keith Randall's avatar
      runtime: get rid of most uses of REP for copying/zeroing. · 6c7cbf08
      Keith Randall authored
      REP MOVSQ and REP STOSQ have a really high startup overhead.
      Use a Duff's device to do the repetition instead.
      
      benchmark                 old ns/op     new ns/op     delta
      BenchmarkClearFat32       7.20          1.60          -77.78%
      BenchmarkCopyFat32        6.88          2.38          -65.41%
      BenchmarkClearFat64       7.15          3.20          -55.24%
      BenchmarkCopyFat64        6.88          3.44          -50.00%
      BenchmarkClearFat128      9.53          5.34          -43.97%
      BenchmarkCopyFat128       9.27          5.56          -40.02%
      BenchmarkClearFat256      13.8          9.53          -30.94%
      BenchmarkCopyFat256       13.5          10.3          -23.70%
      BenchmarkClearFat512      22.3          18.0          -19.28%
      BenchmarkCopyFat512       22.0          19.7          -10.45%
      BenchmarkCopyFat1024      36.5          38.4          +5.21%
      BenchmarkClearFat1024     35.1          35.0          -0.28%
      
      TODO: use for stack frame zeroing
      TODO: REP prefixes are still used for "reverse" copying when src/dst
      regions overlap.  Might be worth fixing.
      
      LGTM=rsc
      R=golang-codereviews, rsc
      CC=golang-codereviews, r
      https://golang.org/cl/81370046
      6c7cbf08
    • Russ Cox's avatar
      cmd/gc: shorten temporary lifetimes when possible · b700cb49
      Russ Cox authored
      The new channel and map runtime routines take pointers
      to values, typically temporaries. Without help, the compiler
      cannot tell when those temporaries stop being needed,
      because it isn't sure what happened to the pointer.
      Arrange to insert explicit VARKILL instructions for these
      temporaries so that the liveness analysis can avoid seeing
      them as "ambiguously live".
      
      The change is made in order.c, which was already in charge of
      introducing temporaries to preserve the order-of-evaluation
      guarantees. Now its job has expanded to include introducing
      temporaries as needed by runtime routines, and then also
      inserting the VARKILL annotations for all these temporaries,
      so that their lifetimes can be shortened.
      
      In order to do its job for the map runtime routines, order.c arranges
      that all map lookups or map assignments have the form:
      
              x = m[k]
              x, y = m[k]
              m[k] = x
      
      where x, y, and k are simple variables (often temporaries).
      Likewise, receiving from a channel is now always:
      
              x = <-c
      
      In order to provide the map guarantee, order.c is responsible for
      rewriting x op= y into x = x op y, so that m[k] += z becomes
      
              t = m[k]
              t2 = t + z
              m[k] = t2
      
      While here, fix a few bugs in order.c's traversal: it was failing to
      walk into select and switch case bodies, so order of evaluation
      guarantees were not preserved in those situations.
      Added tests to test/reorder2.go.
      
      Fixes #7671.
      
      In gc/popt's temporary-merging optimization, allow merging
      of temporaries with their address taken as long as the liveness
      ranges do not intersect. (There is a good chance of that now
      that we have VARKILL annotations to limit the liveness range.)
      
      Explicitly killing temporaries cuts the number of ambiguously
      live temporaries that must be zeroed in the godoc binary from
      860 to 711, or -17%. There is more work to be done, but this
      is a good checkpoint.
      
      Update #7345
      
      LGTM=khr
      R=khr
      CC=golang-codereviews
      https://golang.org/cl/81940043
      b700cb49
  13. 27 Mar, 2014 1 commit
    • Russ Cox's avatar
      cmd/gc: liveness-related bug fixes · 6722d456
      Russ Cox authored
      1. On entry to a function, only zero the ambiguously live stack variables.
      Before, we were zeroing all stack variables containing pointers.
      The zeroing is pretty inefficient right now (issue 7624), but there are also
      too many stack variables detected as ambiguously live (issue 7345),
      and that must be addressed before deciding how to improve the zeroing code.
      (Changes in 5g/ggen.c, 6g/ggen.c, 8g/ggen.c, gc/pgen.c)
      
      Fixes #7647.
      
      2. Make the regopt word-based liveness analysis preserve the
      whole-variable liveness property expected by the garbage collection
      bitmap liveness analysis. That is, if the regopt liveness decides that
      one word in a struct needs to be preserved, make sure it preserves
      the entire struct. This is particularly important for multiword values
      such as strings, slices, and interfaces, in which all the words need
      to be present in order to understand the meaning.
      (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c.)
      
      Fixes #7591.
      
      3. Make the regopt word-based liveness analysis treat a variable
      as having its address taken - which makes it preserved across
      all future calls - whenever n->addrtaken is set, for consistency
      with the gc bitmap liveness analysis, even if there is no machine
      instruction actually taking the address. In this case n->addrtaken
      is incorrect (a nicer way to put it is overconservative), and ideally
      there would be no such cases, but they can happen and the two
      analyses need to agree.
      (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c; test in bug484.go.)
      
      Fixes crashes found by turning off "zero everything" in step 1.
      
      4. Remove spurious VARDEF annotations. As the comment in
      gc/pgen.c explains, the VARDEF must immediately precede
      the initialization. It cannot be too early, and it cannot be too late.
      In particular, if a function call sits between the VARDEF and the
      actual machine instructions doing the initialization, the variable
      will be treated as live during that function call even though it is
      uninitialized, leading to problems.
      (Changes in gc/gen.c; test in live.go.)
      
      Fixes crashes found by turning off "zero everything" in step 1.
      
      5. Do not treat loading the address of a wide value as a signal
      that the value must be initialized. Instead depend on the existence
      of a VARDEF or the first actual read/write of a word in the value.
      If the load is in order to pass the address to a function that does
      the actual initialization, treating the load as an implicit VARDEF
      causes the same problems as described in step 4.
      The alternative is to arrange to zero every such value before
      passing it to the real initialization function, but this is a much
      easier and more efficient change.
      (Changes in gc/plive.c.)
      
      Fixes crashes found by turning off "zero everything" in step 1.
      
      6. Treat wide input parameters with their address taken as
      initialized on entry to the function. Otherwise they look
      "ambiguously live" and we will try to emit code to zero them.
      (Changes in gc/plive.c.)
      
      Fixes crashes found by turning off "zero everything" in step 1.
      
      7. An array of length 0 has no pointers, even if the element type does.
      Without this change, the zeroing code complains when asked to
      clear a 0-length array.
      (Changes in gc/reflect.c.)
      
      LGTM=khr
      R=khr
      CC=golang-codereviews
      https://golang.org/cl/80160044
      6722d456
  14. 19 Mar, 2014 1 commit
  15. 25 Feb, 2014 2 commits
    • Josh Bleecher Snyder's avatar
      5g, 8g: remove dead code · d97d3718
      Josh Bleecher Snyder authored
      maxstksize is superfluous and appears to be vestigial. 6g does not use it.
      
      c >= 4 cannot occur; c = w % 4.
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/68750043
      d97d3718
    • Dave Cheney's avatar
      all: merge NaCl branch (part 1) · 7c8280c9
      Dave Cheney authored
      See golang.org/s/go13nacl for design overview.
      
      This CL is the mostly mechanical changes from rsc's Go 1.2 based NaCl branch, specifically 39cb35750369 to 500771b477cf from https://code.google.com/r/rsc-go13nacl. This CL does not include working NaCl support, there are probably two or three more large merges to come.
      
      CL 15750044 is not included as it involves more invasive changes to the linker which will need to be merged separately.
      
      The exact change lists included are
      
      15050047: syscall: support for Native Client
      15360044: syscall: unzip implementation for Native Client
      15370044: syscall: Native Client SRPC implementation
      15400047: cmd/dist, cmd/go, go/build, test: support for Native Client
      15410048: runtime: support for Native Client
      15410049: syscall: file descriptor table for Native Client
      15410050: syscall: in-memory file system for Native Client
      15440048: all: update +build lines for Native Client port
      15540045: cmd/6g, cmd/8g, cmd/gc: support for Native Client
      15570045: os: support for Native Client
      15680044: crypto/..., hash/crc32, reflect, sync/atomic: support for amd64p32
      15690044: net: support for Native Client
      15690048: runtime: support for fake time like on Go Playground
      15690051: build: disable various tests on Native Client
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/68150047
      7c8280c9
  16. 19 Feb, 2014 1 commit
  17. 15 Feb, 2014 1 commit
    • Russ Cox's avatar
      cmd/gc: correct liveness for fat variables · 7a7c0ffb
      Russ Cox authored
      The VARDEF placement must be before the initialization
      but after any final use. If you have something like s = ... using s ...
      the rhs must be evaluated, then the VARDEF, then the lhs
      assigned.
      
      There is a large comment in pgen.c on gvardef explaining
      this in more detail.
      
      This CL also includes Ian's suggestions from earlier CLs,
      namely commenting the use of mode in link.h and fixing
      the precedence of the ~r check in dcl.c.
      
      This CL enables the check that if liveness analysis decides
      a variable is live on entry to the function, that variable must
      be a function parameter (not a result, and not a local variable).
      If this check fails, it indicates a bug in the liveness analysis or
      in the generated code being analyzed.
      
      The race detector generates invalid code for append(x, y...).
      The code declares a temporary t and then uses cap(t) before
      initializing t. The new liveness check catches this bug and
      stops the compiler from writing out the buggy code.
      Consequently, this CL disables the race detector tests in
      run.bash until the race detector bug can be fixed
      (golang.org/issue/7334).
      
      Except for the race detector bug, the liveness analysis check
      does not detect any problems (this CL and the previous CLs
      fixed all the detected problems).
      
      The net test still fails with GOGC=0 but the rest of the tests
      now pass or time out (because GOGC=0 is so slow).
      
      TBR=iant
      CC=golang-codereviews
      https://golang.org/cl/64170043
      7a7c0ffb
  18. 14 Feb, 2014 2 commits
  19. 12 Feb, 2014 1 commit
  20. 09 Dec, 2013 1 commit
  21. 06 Dec, 2013 1 commit
    • Carl Shapiro's avatar
      cmd/5g, cmd/5l, cmd/6g, cmd/6l, cmd/8g, cmd/8l, cmd/gc, runtime: generate... · f056daf0
      Carl Shapiro authored
      cmd/5g, cmd/5l, cmd/6g, cmd/6l, cmd/8g, cmd/8l, cmd/gc, runtime: generate pointer maps by liveness analysis
      
      This change allows the garbage collector to examine stack
      slots that are determined as live and containing a pointer
      value by the garbage collector.  This results in a mean
      reduction of 65% in the number of stack slots scanned during
      an invocation of "GOGC=1 all.bash".
      
      Unfortunately, this does not yet allow garbage collection to
      be precise for the stack slots computed as live.  Pointers
      confound the determination of what definitions reach a given
      instruction.  In general, this problem is not solvable without
      runtime cost but some advanced cooperation from the compiler
      might mitigate common cases.
      
      R=golang-dev, rsc, cshapiro
      CC=golang-dev
      https://golang.org/cl/14430048
      f056daf0
  22. 17 Sep, 2013 1 commit
    • Russ Cox's avatar
      cmd/gc: eliminate redundant &x.Field nil checks · aa0439ba
      Russ Cox authored
      This eliminates ~75% of the nil checks being emitted,
      on all architectures. We can do better, but we need
      a bit more general support from the compiler, and
      I don't want to do that so close to Go 1.2.
      What's here is simple but effective and safe.
      
      A few small code generation cleanups were required
      to make the analysis consistent on all systems about
      which nil checks are omitted, at least in the test.
      
      Fixes #6019.
      
      R=ken2
      CC=golang-dev
      https://golang.org/cl/13334052
      aa0439ba
  23. 06 Sep, 2013 1 commit
  24. 17 Aug, 2013 1 commit
  25. 16 Aug, 2013 1 commit
  26. 15 Aug, 2013 1 commit
  27. 10 Aug, 2013 1 commit
    • Russ Cox's avatar
      cmd/gc: zero pointers on entry to function · 7910cd68
      Russ Cox authored
      On entry to a function, zero the results and zero the pointer
      section of the local variables.
      
      This is an intermediate step on the way to precise collection
      of Go frames.
      
      This can incur a significant (up to 30%) slowdown, but it also ensures
      that the garbage collector never looks at a word in a Go frame
      and sees a stale pointer value that could cause a space leak.
      (C frames and assembly frames are still possibly problematic.)
      
      This CL is required to start making collection of interface values
      as precise as collection of pointer values are today.
      Since we have to dereference the interface type to understand
      whether the value is a pointer, it is critical that the type field be
      initialized.
      
      A future CL by Carl will make the garbage collection pointer
      bitmaps context-sensitive. At that point it will be possible to
      remove most of the zeroing. The only values that will still need
      zeroing are values whose addresses escape the block scoping
      of the function but do not escape to the heap.
      
      benchmark                         old ns/op    new ns/op    delta
      BenchmarkBinaryTree17            4420289180   4331060459   -2.02%
      BenchmarkFannkuch11              3442469663   3277706251   -4.79%
      BenchmarkFmtFprintfEmpty                100          142  +42.00%
      BenchmarkFmtFprintfString               262          310  +18.32%
      BenchmarkFmtFprintfInt                  213          281  +31.92%
      BenchmarkFmtFprintfIntInt               355          431  +21.41%
      BenchmarkFmtFprintfPrefixedInt          321          383  +19.31%
      BenchmarkFmtFprintfFloat                444          533  +20.05%
      BenchmarkFmtManyArgs                   1380         1559  +12.97%
      BenchmarkGobDecode                 10240054     11794915  +15.18%
      BenchmarkGobEncode                 17350274     19970478  +15.10%
      BenchmarkGzip                     455179460    460699139   +1.21%
      BenchmarkGunzip                   114271814    119291574   +4.39%
      BenchmarkHTTPClientServer             89051        89894   +0.95%
      BenchmarkJSONEncode                40486799     52691558  +30.15%
      BenchmarkJSONDecode                94193361    112428781  +19.36%
      BenchmarkMandelbrot200              4747060      4748043   +0.02%
      BenchmarkGoParse                    6363798      6675098   +4.89%
      BenchmarkRegexpMatchEasy0_32            129          171  +32.56%
      BenchmarkRegexpMatchEasy0_1K            365          395   +8.22%
      BenchmarkRegexpMatchEasy1_32            106          152  +43.40%
      BenchmarkRegexpMatchEasy1_1K            952         1245  +30.78%
      BenchmarkRegexpMatchMedium_32           198          283  +42.93%
      BenchmarkRegexpMatchMedium_1K         79006       101097  +27.96%
      BenchmarkRegexpMatchHard_32            3478         5115  +47.07%
      BenchmarkRegexpMatchHard_1K          110245       163582  +48.38%
      BenchmarkRevcomp                  777384355    793270857   +2.04%
      BenchmarkTemplate                 136713089    157093609  +14.91%
      BenchmarkTimeParse                     1511         1761  +16.55%
      BenchmarkTimeFormat                     535          850  +58.88%
      
      benchmark                          old MB/s     new MB/s  speedup
      BenchmarkGobDecode                    74.95        65.07    0.87x
      BenchmarkGobEncode                    44.24        38.43    0.87x
      BenchmarkGzip                         42.63        42.12    0.99x
      BenchmarkGunzip                      169.81       162.67    0.96x
      BenchmarkJSONEncode                   47.93        36.83    0.77x
      BenchmarkJSONDecode                   20.60        17.26    0.84x
      BenchmarkGoParse                       9.10         8.68    0.95x
      BenchmarkRegexpMatchEasy0_32         247.24       186.31    0.75x
      BenchmarkRegexpMatchEasy0_1K        2799.20      2591.93    0.93x
      BenchmarkRegexpMatchEasy1_32         299.31       210.44    0.70x
      BenchmarkRegexpMatchEasy1_1K        1074.71       822.45    0.77x
      BenchmarkRegexpMatchMedium_32          5.04         3.53    0.70x
      BenchmarkRegexpMatchMedium_1K         12.96        10.13    0.78x
      BenchmarkRegexpMatchHard_32            9.20         6.26    0.68x
      BenchmarkRegexpMatchHard_1K            9.29         6.26    0.67x
      BenchmarkRevcomp                     326.95       320.40    0.98x
      BenchmarkTemplate                     14.19        12.35    0.87x
      
      R=cshapiro
      CC=golang-dev
      https://golang.org/cl/12616045
      7910cd68
  28. 31 Jul, 2013 1 commit
  29. 17 Jul, 2013 1 commit
  30. 16 Jul, 2013 1 commit
  31. 12 Jul, 2013 1 commit
    • Russ Cox's avatar
      cmd/5g, cmd/6g, cmd/8g: fix line number of caller of deferred func · 7e97d398
      Russ Cox authored
      Deferred functions are not run by a call instruction. They are run by
      the runtime editing registers to make the call start with a caller PC
      returning to a
              CALL deferreturn
      instruction.
      
      That instruction has always had the line number of the function's
      closing brace, but that instruction's line number is irrelevant.
      Stack traces show the line number of the instruction before the
      return PC, because normally that's what started the call. Not so here.
      The instruction before the CALL deferreturn could be almost anywhere
      in the function; it's unrelated and its line number is incorrect to show.
      
      Fix the line number by inserting a true hardware no-op with the right
      line number before the returned-to CALL instruction. That is, the deferred
      calls now appear to start with a caller PC returning to the second instruction
      in this sequence:
              NOP
              CALL deferreturn
      
      The traceback will show the line number of the NOP, which we've set
      to be the line number of the function's closing brace.
      
      The NOP here is not the usual pseudo-instruction, which would be
      elided by the linker. Instead it is the real hardware instruction:
      XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM.
      
      Fixes #5856.
      
      R=ken2, ken
      CC=golang-dev
      https://golang.org/cl/11223043
      7e97d398
  32. 28 Jun, 2013 1 commit