| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
Adjustments for changes made in CL 169360043.
This change is already present in the dev.garbage branch.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://codereview.appspot.com/167520044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's just do this up front.
This will break the build (here on the dev.cc branch).
The CLs that follow will take care of fixing it.
Leave behind cmd/cc/lexbody and cmd/cc/macbody for the assemblers.
They'll go away later.
LGTM=dave, r
R=r, dave
CC=golang-codereviews
https://codereview.appspot.com/172170043
|
|
|
|
|
|
|
|
|
|
| |
Follow-up in response to comments on
TBR'ed CL 171260043.
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/172080043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Manifested as increased memory usage in a Google production system.
Not an unbounded leak, but can significantly increase the number
of sudogs allocated between garbage collections.
I checked all the other calls to acquireSudog.
This is the only one that was missing a releaseSudog.
LGTM=r, dneil
R=dneil, r
CC=golang-codereviews
https://codereview.appspot.com/169260043
|
|
|
|
|
|
|
|
|
|
|
| |
These are being built into the runtime/cgo for every
operating system. It doesn't seem to matter, but
restore the Go 1.3 behavior anyway.
LGTM=r
R=r, dave
CC=golang-codereviews
https://codereview.appspot.com/171290043
|
|
|
|
|
|
|
| |
LGTM=dave, bradfitz, r, alex.brainman
R=r, dave, bradfitz, alex.brainman
CC=golang-codereviews
https://codereview.appspot.com/167350043
|
|
|
|
|
|
|
| |
LGTM=bradfitz, r
R=r, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/168320043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a mistake. The cmd/api tool
depends on an old version of go/types.
??? original CL description
cmd/api: use golang.org/x/... import paths
LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/169000043
???
TBR=rsc, bradfitz
R=bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/169320043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a mistake; the cmd/api tool
depends on an old version of go/types.
??? original CL description
cmd/api: bump go.tools golden CL hash
TBR=bradfitz
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/166380043
???
TBR=bradfitz, rsc
R=bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/167430043
|
|
|
|
|
|
|
| |
TBR=bradfitz
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/166380043
|
|
|
|
|
|
|
| |
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/168170043
|
|
|
|
|
|
|
| |
LGTM=rsc, r
R=r, rsc
CC=golang-codereview, golang-codereviews
https://codereview.appspot.com/168050043
|
|
|
|
|
|
|
| |
LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/169000043
|
|
|
|
|
|
|
|
|
|
|
| |
New detection because of net/http now using TestMain.
Fixes Issue 9033
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, rsc
https://codereview.appspot.com/170210043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 9065.
LGTM=rsc
R=rsc, misch
CC=golang-codereviews
https://codereview.appspot.com/171270043
|
|
|
|
|
|
|
|
|
|
| |
This was missing from CL 167320043.
Happy to apply comments in a followup.
TBR to fix build.
TBR=r
CC=golang-codereviews
https://codereview.appspot.com/171260043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving so that new Go 1.4 pprof can use it.
The old 'GNU objdump workalike' mode for 'go tool objdump'
is now gone, as are the tests for that mode. It was used only
by pre-Go 1.4 pprof. You can still specify an address range on
the command line; you just get the same output format as
you do when dumping the entire binary (without an address
limitation).
LGTM=r
R=r
CC=golang-codereviews, iant
https://codereview.appspot.com/167320043
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stack bitmaps need to be scanned past any BitsDead entries.
Object bitmaps will not have any BitsDead in them (bitmap extraction stops at
the first BitsDead entry in makeheapobjbv). data/bss bitmaps also have no BitsDead entries.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/168270043
|
|
|
|
|
|
|
|
|
| |
CL 170720043 missed this one when adding +PCQuantum.
LGTM=iant
R=r, iant
CC=golang-codereviews
https://codereview.appspot.com/168090043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 9046.
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/162680043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.
I don't know how recent the -b option is. If the builders
are ok with it, it's probably ok.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/166220043
|
|
|
|
|
|
|
| |
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/166230044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.
It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.
Not doing this causes faults when you set
StackFromSystem = 1
StackFaultOnFree = 1
The new check in gentraceback will catch future lapses.
The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.
This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, r
https://codereview.appspot.com/167060043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 9020.
LGTM=bradfitz, r
R=r, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/170030043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.
Fixes issue 9020.
LGTM=rsc, adg
R=golang-codereviews, rsc, adg, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/169970043
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test intended to skip direct calls when creating
registerization variables was testing p->to.type instead of
p->to.name, so it always failed, causing regopt to create
unnecessary variables for these names.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/169110043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check for unknown command line debug flags in gc was
incorrect: the loop over debugtab terminates when it reaches a
nil entry, but it was only reporting an error if the parser
had passed the last entry of debugtab (which it never did).
Fix this by reporting the usage error if the loop reaches a
nil entry.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/166110043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the flags argument to mallocgc was an int in Go,
but a uint32 in C. Change the Go type to use uint32 so these
agree. The largest flag value is 2 (and of course no flag
values are negative), so this won't change anything on little
endian architectures, but it matters on big endian.
LGTM=rsc
R=khr, rsc
CC=golang-codereviews
https://codereview.appspot.com/169920043
|
|
|
|
|
|
|
| |
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://codereview.appspot.com/168860044
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using -test.cpu=1,1 made it crash before.
Fixes Issue 9024
LGTM=iant
R=adg, iant
CC=golang-codereviews
https://codereview.appspot.com/169860043
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
LGTM=iant
R=golang-codereviews, iant, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/163690043
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
Fixes Issue 9029
LGTM=adg, r
R=r, adg
CC=golang-codereviews
https://codereview.appspot.com/161630044
|
|
|
|
|
|
|
|
|
| |
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/170770043
Committer: Brad Fitzpatrick <bradfitz@golang.org>
|
|
|
|
|
|
|
|
|
|
|
| |
+ Regression test.
Fixes issue 9026.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/162490043
|
|
|
|
|
|
| |
TBR=adg
CC=golang-codereviews
https://codereview.appspot.com/167890043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.
The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.
To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.
Fixes issue 7690.
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/170720043
|
|
|
|
|
|
|
| |
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/163540043
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.
LGTM=r, iant
R=r, alex.brainman, iant
CC=golang-codereviews
https://codereview.appspot.com/149400043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.
Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.
Change gentraceback to take a flag that specifies whether
we are tracing a trap.
Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.
Add tracebacktrap, like traceback but starting with a trap PC.
Use tracebacktrap in signal handlers.
Fixes issue 7690.
LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://codereview.appspot.com/167810044
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempt to clear up confusion about how to turn
the PCs reported by Callers into the file and line
number people actually want.
Fixes issue 7690.
LGTM=r, chris.cs.guy
R=r, chris.cs.guy
CC=golang-codereviews
https://codereview.appspot.com/163550043
|
|
|
|
|
|
|
|
|
| |
Stupid mistake in previous CL.
TBR=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/166880043
|
|
|
|
|
|
| |
TBR=iant
CC=golang-codereviews
https://codereview.appspot.com/164180043
|
|
|
|
|
|
| |
TBR=austin
CC=golang-codereviews
https://codereview.appspot.com/167820043
|
|
|
|
|
|
| |
TBR=austin
CC=golang-codereviews
https://codereview.appspot.com/162420043
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 8803.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/169720043
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
| |
Fixes issue 9006.
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/167800043
|
|
|
|
|
|
|
|
|
|
|
| |
It now echoes what strconv.FormatFloat says.
Fixes issue 9012.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://codereview.appspot.com/169730043
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 8861.
Fixes issue 8911.
LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/165780043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 8588.
LGTM=austin
R=austin
CC=golang-codereviews, khr
https://codereview.appspot.com/159700044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
goprintf is a printf-like print for Go.
It is used in the code generated by 'defer print(...)' and 'go print(...)'.
Normally print(1, 2, 3) turns into
printint(1)
printint(2)
printint(3)
but defer and go need a single function call to give the runtime;
they give the runtime something like goprintf("%d%d%d", 1, 2, 3).
Variadic functions like goprintf cannot be described in the new
type information world, so we have to replace it.
Replace with a custom function, so that defer print(1, 2, 3) turns
into
defer func(a1, a2, a3 int) {
print(a1, a2, a3)
}(1, 2, 3)
(and then the print becomes three different printints as usual).
Fixes issue 8614.
LGTM=austin
R=austin
CC=golang-codereviews, r
https://codereview.appspot.com/159700043
|