- 12 Oct, 2017 10 commits
-
-
Austin Clements authored
The .debug_aranges section is an odd vestige of DWARF, since its contents are easy and efficient for a debugger to reconstruct from the attributes of the top-level compilation unit DIEs. Neither GCC nor clang emit it by default these days. GDB and Delve ignore it entirely. LLDB will use it if present, but is happy to construct the index from the compilation unit attributes (and, indeed, a remarkable variety of other ways if those aren't available either). We're about to split up the compilation units by package, which means they'll have discontiguous PC ranges, which is going to make .debug_aranges harder to construct (and larger). Rather than try to maintain this essentially unused code, let's simplify things and remove it. Change-Id: I8e0ccc033b583b5b8908cbb2c879b2f2d5f9a50b Reviewed-on: https://go-review.googlesource.com/69972 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Heschi Kreinick <heschi@google.com> Reviewed-by:
Than McIntosh <thanm@google.com>
-
Heschi Kreinick authored
During Mach-O linking, dsymutil takes the DWARF from individual object files and combines it into a debug archive. Because it's content-aware, it doesn't need our help to do its job. Nonetheless, it does try to honor relocations that are present in its input. When dsymutil encounters a relocation, it uses the value of that relocation as an index into the debug map to find its final location. When it does that, it's assuming that the value is an address in the object file. But DWARF references are section-relative. So when it processes a relocation for a DWARF reference, it gets confused, and if the value happens to match the address of a function or data symbol, it will rewrite it incorrectly. Since the relocations don't help, and can hurt, drop them when externally linking a Mach-O binary. Fixes #22068 Change-Id: I8ec36da626575d9f6c8d0e7a0b76eab8ba22d62c Reviewed-on: https://go-review.googlesource.com/68330 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Elias Naur authored
The alternative signal stack doesn't work on ios, so the setup of the alternative stack was skipped. The corresponding unminitSignals was effectively a no-op on ios until CL 70130. Skip unminitSignals on ios to restore the previous behaviour. For the ios builders. Change-Id: I5692ca7f5997e6b9d10cc5f2383a5a37c42b133c Reviewed-on: https://go-review.googlesource.com/70270 Run-TryBot: Elias Naur <elias.naur@gmail.com> Reviewed-by:
Austin Clements <austin@google.com>
-
Russ Cox authored
The two are not meaningfully different, and it is confusing to have two. Change-Id: Ie6a355ea4d79fb4bb79bf5124071a866038b19ba Reviewed-on: https://go-review.googlesource.com/70211 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alex Brainman authored
CL 36799 made SetFileCompletionNotificationModes to be called for file handles. I don't think it is correct. Revert that change. Fixes #22024 Fixes #22207 Change-Id: I26260e8a727131cffbf60958d79eca2457495554 Reviewed-on: https://go-review.googlesource.com/69871Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Alex Brainman authored
Current code assumes that SetFileCompletionNotificationModes is safe to call even if we know that it is not safe to use FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. It appears (see issue #22149), SetFileCompletionNotificationModes crashes when we call it without FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. Do not call SetFileCompletionNotificationModes in that situation. We are allowed to do that, because SetFileCompletionNotificationModes is just an optimisation. Fixes #22149 Change-Id: I0ad3aff4eabd8c27739417a62c286b1819ae166a Reviewed-on: https://go-review.googlesource.com/69870Reviewed-by:
-
Artyom Pervukhin authored
Decode decodes entire GIF image and returns the first frame as an image.Image. There's no need for it to keep every decoded frame in memory except for the one it returns. Fixes #22199 Change-Id: I76b4bd31608ebc76a1a3df02e85c20eb80df7877 Reviewed-on: https://go-review.googlesource.com/69890Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Austin Clements authored
CL 69292 unified the amd64 entry-points, but Dragonfly doesn't follow the same entry-point argument conventions as most other amd64 platforms. Fix the Dragonfly entry point. Change-Id: I0f84e2e4101ce68217af185ee9baaf455b8b6dad Reviewed-on: https://go-review.googlesource.com/70212 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Ian Lance Taylor authored
Fixes #21054 Change-Id: I016486dc62c04a80727f8da7d1dcec52f2c7f344 Reviewed-on: https://go-review.googlesource.com/62291Reviewed-by:
Giovanni Bajo <rasky@develer.com> Reviewed-by:
Chris Broadfoot <cbro@golang.org>
-
David du Colombier authored
Since CL 46037, the runtime is crashing after calling exitThread on Plan 9. The exitThread function shouldn't be called on Plan 9, because the system manages thread stacks. Fixes #22221. Change-Id: I5d61c9660a87dc27e4cfcb3ca3ddcb4b752f2397 Reviewed-on: https://go-review.googlesource.com/70190 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 11 Oct, 2017 30 commits
-
-
Matthew Dempsky authored
Previously, we were treating cross-package function calls as free for inlining budgeting. In theory, we should be able to recompute InlCost from the exported/reimported function bodies. However, that process mutates the structure of the Node AST enough that it doesn't preserve InlCost. To avoid unexpected issues, just record and restore InlCost in the export data. Fixes #19261. Change-Id: Iac2bc0d32d4f948b64524aca657051f9fc96d92d Reviewed-on: https://go-review.googlesource.com/70151 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Daniel Martí authored
Noticed while reading some code that the two branches in this loop body shared the last statements. Rewrite it in a way that they are not duplicated. Passes toolstash -cmp on std. Change-Id: I3356ca9fa37c32eee496e221d7830bfc581dade1 Reviewed-on: https://go-review.googlesource.com/66470 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Hugues Bruant authored
Calls to a closure held in a local, non-escaping, variable can be inlined, provided the closure body can be inlined and the variable is never written to. The current implementation has the following limitations: - closures with captured variables are not inlined because doing so naively triggers invariant violation in the SSA phase - re-assignment check is currently approximated by checking the Addrtaken property of the variable which should be safe but may miss optimization opportunities if the address is not used for a write before the invocation Updates #15561 Change-Id: I508cad5d28f027bd7e933b1f793c14dcfef8b5a1 Reviewed-on: https://go-review.googlesource.com/65071 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Austin Clements authored
Android's libc creates a signal stack for every thread it creates. In Go, minitSignalStack picks up this existing signal stack and puts it in m.gsignal.stack. However, if we later try to exit a thread (because a locked goroutine is exiting), we'll attempt to stackfree this libc-allocated signal stack and panic. Fix this by clearing gsignal.stack when we unminitSignals in such a situation. This should fix the Android build, which is currently broken. Change-Id: Ieea8d72ef063d22741c54c9daddd8bb84926a488 Reviewed-on: https://go-review.googlesource.com/70130Reviewed-by:
-
Joe Tsai authored
In #10909, it was decided that "Deprecated:" is a magic string for tools (e.g., #17056 for godoc) to detect deprecated identifiers. Use those convention instead of custom written prose. Change-Id: Ia514fc3c88fc502e86c6e3de361c435f4cb80b22 Reviewed-on: https://go-review.googlesource.com/70110Reviewed-by:
-
David Chase authored
In order to improve the line numbering for debuggers, it's necessary to trace lines through compilation. This makes it (much) easier to follow. The format of the last column of the ssa.html output was also changed to reduce the spamminess of the file name, which is usually the same and makes it far harder to read instructions and line numbers, and to make it wider and also able to break words when wrapping (long path names still can push off the end otherwise; side-to-side scrolling was tried but was more annoying than the occasional wrapped line). Sample output now, where [...] is elision for sake of making the CL character-counter happy -- and the (##) line numbers are rendered in italics and a smaller font (11 point) under control of a CSS class "line-number". genssa # /Users/drchase/[...]/ssa/testdata/hist.go 00000 (35) TEXT "".main(SB) 00001 (35) FUNCDATA $0, gclocals·7be4bb[...]1e8b(SB) 00002 (35) FUNCDATA $1, gclocals·9ab98a[...]4568(SB) v920 00003 (36) LEAQ ""..autotmp_31-640(SP), DI v858 00004 (36) XORPS X0, X0 v6 00005 (36) LEAQ -48(DI), DI v6 00006 (36) DUFFZERO $277 v576 00007 (36) LEAQ ""..autotmp_31-640(SP), AX v10 00008 (36) TESTB AX, (AX) b1 00009 (36) JMP 10 and from an earlier phase: b18: ← b17 v242 (47) = Copy <mem> v238 v243 (47) = VarKill <mem> {.autotmp_16} v242 v244 (48) = Addr <**bufio.Scanner> {scanner} v2 v245 (48) = Load <*bufio.Scanner> v244 v243 [...] v279 (49) = Store <mem> {int64} v277 v276 v278 v280 (49) = Addr <*error> {.autotmp_18} v2 v281 (49) = Load <error> v280 v279 v282 (49) = Addr <*error> {err} v2 v283 (49) = VarDef <mem> {err} v279 v284 (49) = Store <mem> {error} v282 v281 v283 v285 (47) = VarKill <mem> {.autotmp_18} v284 v286 (47) = VarKill <mem> {.autotmp_17} v285 v287 (50) = Addr <*error> {err} v2 v288 (50) = Load <error> v287 v286 v289 (50) = NeqInter <bool> v288 v51 If v289 → b21 b22 (line 50) Change-Id: I3f46310918f965761f59e6f03ea53067237c28a8 Reviewed-on: https://go-review.googlesource.com/69591 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Cherry Zhang <cherryyz@google.com>
-
Ian Lance Taylor authored
This adds the _lib entry point to various GOOS_amd64.s files. A future CL will enable c-archive/c-shared mode for those targets. As far as I can tell, the newosproc0 function in os_darwin.go was passing the wrong arguments to bsdthread_create. The newosproc0 function is never called in the current testsuite. Change-Id: Ie7c1c2e326cec87013e0fea84f751091b0ea7f51 Reviewed-on: https://go-review.googlesource.com/69711 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Lynn Boger authored
Starting in gcc 6, -pie is passed to the linker by default on some platforms, including ppc64le. If the objects being linked are not built for -pie then in some cases the executable could be in error. To avoid that problem, -no-pie should be used with gcc to override the default -pie option and generate a correct executable that can be run without error. Fixes #22126 Change-Id: I4a052bba8b9b3bd6706f5d27ca9a7cebcb504c95 Reviewed-on: https://go-review.googlesource.com/70072 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Crawshaw authored
Along the way, switch to using relocation constants from debug/elf. For #22095 Change-Id: I1a64353619f95dde5aa39060c4b9d001af7dc1e4 Reviewed-on: https://go-review.googlesource.com/69013 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cherry Zhang authored
It should be skipped on 32-bit architectures. Change-Id: If7a64b9e90e47c3e8734dd62729bfd2944ae926c Reviewed-on: https://go-review.googlesource.com/70071Reviewed-by:
-
Russ Cox authored
Change-Id: Iaa960c85011289e047c64b53cf610838eb50332d Reviewed-on: https://go-review.googlesource.com/70073 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
All of the amd64 entry point code is the same except for Plan 9. Unify it all into asm_amd64.s. Change-Id: Id47ce3a7bb2bb0fd48f326a2d88ed18b17dee456 Reviewed-on: https://go-review.googlesource.com/69292 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Austin Clements authored
There are two places in DWARF generation that create symbols when they really just want to get the symbol if it exists. writeranges, in particular, will create a DWARF range symbol for every single textp symbol (though they won't get linked into any list, so they don't affect the binary). Fix these to use ROLookup instead of Lookup. Change-Id: I401eadf22890e296bd08bccaa6ba2fd8fac800cd Reviewed-on: https://go-review.googlesource.com/69971 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
In the distant past, Pipe was implemented with channels and a long running pipe.run goroutine (see CL 994043). This approach of having all communication serialized through the run method was error prone giving Pipe a history of deadlocks and race conditions. After the introduction of sync.Cond, the implementation was rewritten (see CL 4252057) to use condition variables and avoid the long running pipe.run goroutine. While this implementation is superior to the previous one, this implementation is strange in that the p.data field is always set immediately prior to signaling the other goroutine with Cond.Signal, effectively making the combination of the two a channel-like operation. Inferior to a channel, however, this still requires explicit locking around the p.data field. The data+rwait can be effectively be replaced by a "chan []byte" to inform a reader that there is data available. The data+wwait can be effectively be replaced by a "chan int" to inform a writer of how many bytes were read. This implementation is a simplified from net.Pipe in CL 37402. Change-Id: Ia5b26320b0525934fd87a3b69a091c787167f5aa Reviewed-on: https://go-review.googlesource.com/65330 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan Mills <bcmills@google.com>
-
Joe Tsai authored
Implement deadline functionality on Pipe so that it properly implements the semantics of the Conn interface. This aids usages of Pipe (often in unit tests) with a more realistic and complete implementation. The new implementation avoids a dependency on a io.Pipe since it is impossible to keep the prior semantics of synchronous reads and writes while also trying to implement cancelation over an io.{Reader,Writer} that fundamentally has no cancelation support. The fact that net.Pipe is synchronous (and documented as such) is unfortunate because no realistic network connection is synchronous. Instead real networks introduces a read and write buffer of some sort. However, we do not change the semantics for backwards compatibility. The approach taken does not leave any long-running goroutines, meaning that tests that never call Close will not cause a resource leak. Fixes #18170 Change-Id: I5140b1f289a0a49fb2d485f031b5aa0ee99ecc30 Reviewed-on: https://go-review.googlesource.com/37402 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
On Windows, not closing f keeps us from being able to remove it. Change-Id: Id4cb709b6ce0b30485b87364a9f0e6e71d2782bd Reviewed-on: https://go-review.googlesource.com/70070 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
It looks like I forgot to reenable this test when I fixed #21522. Update deps.go and reenable. Change-Id: I68a45df09b418f48d93d2e7ab1d274e056c192e6 Reviewed-on: https://go-review.googlesource.com/70050 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
The content ID will be needed for content-based staleness determination. It is defined as the SHA256 hash of the file in which it appears, with occurrences of the build+content IDs changed to zeros during the hashing operation. Storing the content ID in the archives is a little tricky but it means that later builds need not rehash the archives each time they are referenced, so under the assumption that each package is imported at least once after being compiled, hashing at build time is a win. (Also the whole file is more likely to be in cache at build time, since we just wrote it.) In my unscientific tests, the time for "go build -a std cmd" rises from about 14.3s to 14.5s on my laptop, or under 2%. Change-Id: Ia3d4dc657d003e8295631f73363868bd92ebf96a Reviewed-on: https://go-review.googlesource.com/69054Reviewed-by:
-
Austin Clements authored
The liveness analysis no longer directly emits PCDATA. Fix stale comments that say so. Change-Id: Id26b112ddf4c13a12ebf766f64bf57c68fbfe3ef Reviewed-on: https://go-review.googlesource.com/67691 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
If the stack frame is too large, abort immediately. We used to generate code first, then abort. In issue 22200, generating code raised a panic so we got an ICE instead of an error message. Change the max frame size to 1GB (from 2GB). Stack frames between 1.1GB and 2GB didn't used to work anyway, the pcln table generation would have failed and generated an ICE. Fixes #22200 Change-Id: I1d918ab27ba6ebf5c87ec65d1bccf973f8c8541e Reviewed-on: https://go-review.googlesource.com/69810 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
-
Keith Randall authored
Fixes #22198 Change-Id: I5cb91c73069af8b16a2580d28756efd58c84b690 Reviewed-on: https://go-review.googlesource.com/69990 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
This CL does a few things. 1. It moves the existing "read a build ID" code out of the go command and into cmd/internal/buildid. 2. It adds new code there to "write a build ID". 3. It adds better tests. 4. It encapsulates cmd/internal/buildid into a new standalone program "go tool buildid". The go command is going to use the new "write a build ID" functionality in a future CL. Adding the separate "go tool buildid" gives "go build -x" a printable command to explain what it is doing in that new step. (This is similar to the go command printing "go tool pack" commands equivalent to the actions it is taking, even though it's not invoking pack directly.) Keeping go build -x honest means that other build systems can potentially keep up with the go command. Change-Id: I01c0a66e30a80fa7254e3f2879283d3cd7aa03b4 Reviewed-on: https://go-review.googlesource.com/69053Reviewed-by:
-
Austin Clements authored
This makes it more obvious which of the two builds is failing by putting "dbg" or "opt" directly in the test name. It also makes it possible for them to fail independently, so a failure in "dbg" doesn't mask a failure in "opt", and to visibly skip the opt test when run with an unoptimized runtime. Change-Id: I3403a7fd3c1a13ad51a938bb95dfe54c320bb58e Reviewed-on: https://go-review.googlesource.com/69970 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Austin Clements authored
Right now users have to infer why they would want LockOSThread and when it may or may not be appropriate to call UnlockOSThread. This requires some understanding of Go's internal thread pool implementation, which is unfortunate. Improve the situation by making the documentation on these functions more prescriptive so users can figure out when to use them even if they don't know about the scheduler. Change-Id: Ide221791e37cb5106dd8a172f89fbc5b3b98fe32 Reviewed-on: https://go-review.googlesource.com/52871 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
runtime.LockOSThread is sometimes used when the caller intends to put the OS thread into an unusual state. In this case, we never want to return this thread to the runtime thread pool. However, currently exiting the goroutine implicitly unlocks its OS thread. Fix this by terminating the locked OS thread when its goroutine exits, rather than simply returning it to the pool. Fixes #20395. Change-Id: I3dcec63b200957709965f7240dc216fa84b62ad9 Reviewed-on: https://go-review.googlesource.com/46038 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, threads created by the runtime exist until the whole program exits. For #14592 and #20395, we want to be able to exit and clean up threads created by the runtime. This commit implements that mechanism. The main difficulty is how to clean up the g0 stack. In cgo mode and on Solaris and Windows where the OS manages thread stacks, we simply arrange to return from mstart and let the system clean up the thread. If the runtime allocated the g0 stack, then we use a new exitThread syscall wrapper that arranges to clear a flag in the M once the stack can safely be reaped and call the thread termination syscall. exitThread is based on the existing exit1 wrapper, which was always meant to terminate the calling thread. However, exit1 has never been used since it was introduced 9 years ago, so it was broken on several platforms. exitThread also has the additional complication of having to flag that the stack is unused, which requires some tricks on platforms that use the stack for syscalls. This still leaves the problem of how to reap the unused g0 stacks. For this, we move the M from allm to a new freem list as part of the M exiting. Later, allocm scans the freem list, finds Ms that are marked as done with their stack, removes these from the list and frees their g0 stacks. This also allows these Ms to be garbage collected. This CL does not yet use any of this functionality. Follow-up CLs will. Likewise, there are no new tests in this CL because we'll need follow-up functionality to test it. Change-Id: Ic851ee74227b6d39c6fc1219fc71b45d3004bc63 Reviewed-on: https://go-review.googlesource.com/46037 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Every cmd/thing is 'go tool thing' except for go and gofmt. But the table in cmd/go enumerates all the things instead of saying that go and gofmt are the exceptions. Change that, so that when adding new tools it's not necessary to update this table. Change-Id: Ia6fef41b4d967249b19971a0d03e5acb0317ea82 Reviewed-on: https://go-review.googlesource.com/69052 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, since Ms never exit, the number of Ms, the number of Ms ever created, and the ID of the next M are all the same and must be small. That's about to change, so rename sched.mcount to sched.mnext to make it clear it's the number of Ms ever created (and the ID of the next M), change its type to int64, and use mcount() for the number of Ms. In the next commit, mcount() will become slightly less trivial. For #20395. Change-Id: I9af34d36bd72416b5656555d16e8085076f1b196 Reviewed-on: https://go-review.googlesource.com/68750 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Today they happen during the build phase; they should happen during the load phase instead, along with the C check. Change-Id: I6074a995b8e29275549aafa574511b735642d85b Reviewed-on: https://go-review.googlesource.com/69051 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
mstart is the entry point for new threads, so it certainly can't interact with GC enough to have write barriers. We move the one small piece that is allowed to have write barriers out into its own function. Change-Id: Id9c31d6ffac31d0051fab7db15eb428c11cadbad Reviewed-on: https://go-review.googlesource.com/46035 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
