This prevents the temporary directory from being leaked when
the linker is run on a FUSE filesystem.
Fixes#8684.
LGTM=bradfitz
R=golang-codereviews, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/141840043
This fixes the bug in which the linker reports "missing Go
type information" when a -X option refers to a symbol that is
not used.
Fixes#8821.
LGTM=rsc
R=rsc, r
CC=golang-codereviews
https://golang.org/cl/151000043
The extra-clever code in Sincos is trying to do
if v&2 == 0 {
mask = 0xffffffffffffffff
} else {
mask = 0
}
It does this by turning v&2 into a float64 X0 and then using
MOVSD $0.0, X3
CMPSD X0, X3, 0
That CMPSD is defined to behave like:
if X0 == X3 {
X3 = 0xffffffffffffffff
} else {
X3 = 0
}
which gives the desired mask in X3. The goal in using the
CMPSD was to avoid a conditional branch.
This code fails when called from a PortAudio callback.
In particular, the failure behavior is exactly as if the
CMPSD always chose the 'true' execution.
Notice that the comparison X0 == X3 is comparing as
floating point values the 64-bit pattern v&2 and the actual
floating point value zero. The only possible values for v&2
are 0x0000000000000000 (floating point zero)
and 0x0000000000000002 (floating point 1e-323, a denormal).
If they are both comparing equal to zero, I conclude that
in a PortAudio callback (whatever that means), the processor
is running in "denormals are zero" mode.
I confirmed this by placing the processor into that mode
and running the test case in the bug; it produces the
incorrect output reported in the bug.
In general, if a Go program changes the floating point math
modes to something other than what Go expects, the math
library is not going to work exactly as intended, so we might
be justified in not fixing this at all.
However, it seems reasonable that the client code might
have expected "denormals are zero" mode to only affect
actual processing of denormals. This code has produced
what is in effect a gratuitous denormal by being extra clever.
There is nothing about the computation being requested
that fundamentally requires a denormal.
It is also easy to do this computation in integer math instead:
mask = ((v&2)>>1)-1
Do that.
For the record, the other math tests that fail if you put the
processor in "denormals are zero" mode are the tests for
Frexp, Ilogb, Ldexp, Logb, Log2, and FloatMinMax, but all
fail processing denormal inputs. Sincos was the only function
for which that mode causes incorrect behavior on non-denormal inputs.
The existing tests check that the new assembly is correct.
There is no test for behavior in "denormals are zero" mode,
because I don't want to add assembly to change that.
Fixes#8623.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews, iant, r
https://golang.org/cl/151750043
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
From issue 7967 I learned:
1) yacc accepts either 'x' or "x" to mean token value 0x78
2) yacc also accepts 'xyz' and "XYZ" to mean token value 0x78
Use strconv.Unquote to simplify the handling of quoted
strings and check that each has only one rune.
Although this does clean things up, it makes 'x' and "x"
treated as different internally (now they are stored as
`'x'` and `"x"`; before they were both ` x`). Grammars that
use both interchangeably will now die with an error
similar to the one from issue 7967:
yacc bug -- cannot have 2 different Ts with same value
"+" and '+'
The echoing of the quotes should make clear what is going on.
The other semantic change caused by using strconv.Unquote
is that '\"' and "\'" are no longer valid. Like in Go, they must be
spelled without the backslash: '"' and "'".
On the other hand, now yacc and Go agree about what character
and string literals mean.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/149110043
The one line that you can't test easily was broken.
This manifested as a failure of a pre-existing test
in test.bash but I didn't notice it (there are a few other
long-standing failures that need to be fixed).
TBR=r
CC=golang-codereviews
https://golang.org/cl/146340044
Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.
The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.
During development work, however, you do want install -a
to rebuild everything, because anything might have changed.
Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.
This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.
Fixes#8290.
LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045
This fixes the test/linkx.go test, which does not run by default.
(Issue 4139 is about fixing that.)
Fixes#8806.
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/145420043
Also rebuild doc.go; was stale, so contains extra changes.
Fixes#8677.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/148170043
While we are here, remove undocumented, meaningless test -file flag.
Fixes#7724.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/149070043
Fix by atom (from CL 89190044), comment and test by me.
Fixes#6823.
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=0xe2.0x9a.0x9b, adg, golang-codereviews, iant, r
https://golang.org/cl/148180043
If you say 'go get -v' you get extra information when import
paths are not of the expected form.
If you say 'go get -v src/rsc.io/pdf' the message says that
src/rsc.io/pdf does not contain a hostname, which is incorrect.
The problem is that it does not begin with a hostname.
Fixes#7432.
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/144650043
If you do 'go get -u rsc.io/pdf' and then rsc.io/pdf's redirect
changes to point somewhere else, after this CL a later
'go get -u rsc.io/pdf' will tell you that.
Fixes#8548.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, n13m3y3r, r
https://golang.org/cl/147170043
The pattern was only working if the checkout had
already been done, but the code was trying to make
it work even the first time. Test and fix.
Fixes#8335.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/146310043
Need to restore the g register. Somehow this line vaporized from
CL 144130043. Also cgo_topofstack -> _cgo_topofstack, that vaporized also.
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/150940044
During a cgo call, the stack can be copied. This copy invalidates
the pointer that cgo has into the return value area. To fix this
problem, pass the address of the location containing the stack
top value (which is in the G struct). For cgo functions which
return values, read the stktop before and after the cgo call to
compute the adjustment necessary to write the return value.
Fixes#8771
LGTM=iant, rsc
R=iant, rsc, khr
CC=golang-codereviews
https://golang.org/cl/144130043
Not sure why they used empty.s and all these other
packages were special cased in cmd/go instead.
Add them to the list.
This avoids problems with net .s files being compiled
with gcc in cgo mode and gcc not supporting // comments
on ARM.
Not a problem with bytes, but be consistent.
The last change fixed the ARM build but broke the Windows build.
Maybe *this* will make everyone happy. Sigh.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/144530046
In cgo mode it gets passed to gcc, and on ARM
it appears that gcc does not support // comments.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142640043
Fixes linux builds (_vdso); may fix others.
I can at least cross-compile cmd/go for every
implemented system now.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142630043
Should fix the Windows build. Untested.
on Windows, args are made by src/os/exec_windows.go, not package runtime.
runtime·goargs has if(Windows) return;
The two init funcs in pkg os were conflicting, with the second
overwriting Args back to an empty slice.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/143540044
Corrections due to new strict type rules for data+bss.
Also disable misc/cgo/cdefstest since you can't compile C code anymore.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/148050044
Previous behavior was undocumented and inconsistent. Now it is documented
and consistent and measures the input size, since that makes more sense
when talking about %q and %x. For %s the change has no effect.
Fixes#8151.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/144540044
In linker, refuse to write conservative (array of pointers) as the
garbage collection type for any variable in the data/bss GC program.
In the linker, attach the Go type to an already-read C declaration
during dedup. This gives us Go types for C globals for free as long
as the cmd/dist-generated Go code contains the declaration.
(Most runtime C declarations have a corresponding Go declaration.
Both are bss declarations and so the linker dedups them.)
In cmd/dist, add a few more C files to the auto-Go-declaration list
in order to get Go type information for the C declarations into the linker.
In C compiler, mark all non-pointer-containing global declarations
and all string data as NOPTR. This allows them to exist in C files
without any corresponding Go declaration. Count C function pointers
as "non-pointer-containing", since we have no heap-allocated C functions.
In runtime, add NOPTR to the remaining pointer-containing declarations,
none of which refer to Go heap objects.
In runtime, also move os.Args and syscall.envs data into runtime-owned
variables. Otherwise, in programs that do not import os or syscall, the
runtime variables named os.Args and syscall.envs will be missing type
information.
I believe that this CL eliminates the final source of conservative GC scanning
in non-SWIG Go programs, and therefore...
Fixes#909.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/149770043
Those C files would have been compiled with 6c.
It's close to impossible to use C correctly anymore,
and the C compilers are going away eventually.
Make them unavailable now.
go1.4.txt change in CL 145890046
LGTM=iant
R=iant
CC=golang-codereviews, r
https://golang.org/cl/149720043
Normally, the caller to runtime.entersyscall() must not return before
calling runtime.exitsyscall(), lest g->syscallsp become a dangling
pointer. runtime.cgocallbackg() violates this constraint. To work around
this, save g->syscallsp and g->syscallpc around cgo->Go callbacks, then
restore them after calling runtime.entersyscall(), which restores the
syscall stack frame pointer saved by cgocall. This allows the GC to
correctly trace a goroutine that is currently returning from a
Go->cgo->Go chain.
This also adds a check to proc.c that panics if g->syscallsp is clearly
invalid. It is not 100% foolproof, as it will not catch a case where the
stack was popped then pushed back beyond g->syscallsp, but it does catch
the present cgo issue and makes existing tests fail without the bugfix.
Fixes#7978.
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, minux, bradfitz, iant, gobot, rsc
CC=golang-codereviews, rsc
https://golang.org/cl/131910043
There were at least two bugs:
1) It would overwrite a non-archive.
2) It would truncate a non-archive and then fail.
In general the file handling was too clever to be correct.
Make it more straightforward, doing the creation
separately from archive management.
Fixes#8369.
LGTM=adg, iant
R=golang-codereviews, adg, iant
CC=golang-codereviews
https://golang.org/cl/147010046
Was just a missing case (literally) in the type checker.
Fixes#8473.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/142460043
Previously, signed and unsigned integers could not be compared, but
this has problems with things like comparing 'x' with a byte in a string.
Since signed and unsigned integers have a well-defined ordering,
even though their types are different, and since we already allow
comparison regardless of the size of the integers, why not allow it
regardless of the sign?
Integers only, a fine place to draw the line.
Fixes#7489.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/149780043
Saw this on a test:
runtime: bad pointer in frame runtime_test.testSetPanicOnFault at 0xc20801c6b0: 0xfff
fatal error: bad pointer!
runtime stack:
...
copystack(0xc2081bf7a0, 0x1000)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:621 +0x173 fp=0xfffffd7ffd5ffee0 sp=0xfffffd7ffd5ffe20
runtime.newstack()
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:774 +0x552 fp=0xfffffd7ffd5fff90 sp=0xfffffd7ffd5ffee0
runtime.morestack()
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/asm_amd64.s:324 +0x90 fp=0xfffffd7ffd5fff98 sp=0xfffffd7ffd5fff90
goroutine 163354 [stack growth]:
...
runtime.convT2E(0x587000, 0xc20807bea8, 0x0, 0x0)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/iface.go:141 +0xd2 fp=0xc20801c678 sp=0xc20801c640
runtime_test.testSetPanicOnFault(0xc20822c510, 0xfff, 0xc20801c748)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/runtime_test.go:211 +0xc6 fp=0xc20801c718 sp=0xc20801c678
...
This test is testing bad pointers. It loads the bad pointer into a pointer variable,
but before it gets a chance to dereference it, calls convT2E. That call causes a stack copy,
which exposes that live but bad pointer variable.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/146880043
When running defers, we must check whether the defer
has already been marked as started so we don't run it twice.
Fixes#8774.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/142280044
Pure renaming. This will make an upcoming CL have smaller diffs.
LGTM=dvyukov, iant
R=iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/142280043
CL 144940043 renamed it from Sched to SchedType
to avoid a lowercasing conflict in the Go code with
the variable named sched.
We've been using just T resolve those conflicts, not Type.
The FooType pattern is already taken for the kind-specific
variants of the runtime Type structure: ChanType, MapType,
and so on. SchedType isn't a Type.
LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/145180043
Update #8690
If liblink determines that the host doesn't support TLS it replaces the MRC call with a BL runtime.tls_read_fallback. The problem is save_g doesn't expect anyone to make any BL calls and hasn't setup its own link register properly so when runtime.tls_read_fallback returns the LR points to save_g, not save_g's caller so the RET at the end of the function turns into an infinite loop.
This fix is only a proof of concept, I think the real fix should go into liblink as its MRC substitution is not as transparent as expected.
LGTM=rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/143050043
We can't assume all those addresses are unmapped.
But at least one should be.
What we're really testing is that the program doesn't crash.
Fixes#8542.
LGTM=iant
R=golang-codereviews, iant, minux
CC=golang-codereviews
https://golang.org/cl/144120043
We mark DBG_PRINTEXCEPTION_C messages in VEH handler
as handled, thus preventing debugger from seeing them.
I don't see reason for doing that. The comment warns
of crashes, but I added test and don't see any crashes.
This is also simplify VEH handler before making
changes to fix issue 8006.
Update #8006
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/146800043
This is to simplify VEH handler before making
changes to fix issue 8006.
Update #8006
LGTM=adg, rsc
R=golang-codereviews, adg, rsc
CC=golang-codereviews
https://golang.org/cl/138630043
Same fix as for SysUnused.
Fixes#8038.
LGTM=iant, alex.brainman
R=golang-codereviews, iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/147820043
The current Windows build failure happens because by
default runtime frames are excluded from stack traces.
Apparently the Windows breakpoint path dies with an
ordinary panic, while the Unix path dies with a throw.
Breakpoint is a strange function and I don't mind that it's
a little different on the two operating systems.
The panic squelches runtime frames but the throw shows them,
because throw is considered something that shouldn't have
happened at all, so as much detail as possible is wanted.
The runtime exclusion is meant to prevents printing too much noise
about internal runtime details. But exported functions are
not internal details, so show exported functions.
If the program dies because you called runtime.Breakpoint,
it's okay to see that frame.
This makes the Breakpoint test show Breakpoint in the
stack trace no matter how it is handled.
Should fix Windows build.
Tested on Unix by changing Breakpoint to fault instead
of doing a breakpoint.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/143300043
This fixes a couple of problems that occur when the linker
removes its temporary directory on Windows. The linker only
creates and removes a temporary directory when doing external
linking. Windows does not yet support external linking.
Therefore, these problems are only seen when using a
cross-compiler hosted on Windows.
In lib9, FindFirstFileW returns just the file name, not the
full path name. Don't assume that we will find a slash.
Changed the code to work either way just in case.
In ld, Windows requires that files be closed before they are
removed, so close the output file before we might try to
remove it.
Fixes#8723.
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=golang-codereviews
https://golang.org/cl/141690043
It's just fundamentally incompatible with
Windows' pickiness about removing things
that are in use.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/142270043
Since CL 130990043, the GOTRACEBACK variable is
only used when the GODEBUG variable is set.
This change restores the original behavior.
LGTM=rsc
R=golang-codereviews, aram, gobot, r, rsc
CC=golang-codereviews
https://golang.org/cl/132520043
In Go 1.3 the runtime called panicstring to report errors like
divide by zero or memory faults. Now we call panic (gopanic)
with pre-allocated error values. That new path is missing the
checking that panicstring did, so add it there.
The only call to panicstring left is in cnew, which is problematic
because if it fails, probably the heap is corrupt. In that case,
calling panicstring creates a new errorCString (no allocation there),
but then panic tries to print it, invoking errorCString.Error, which
does a string concatenation (allocating), which then dies.
Replace that one panicstring with a throw: cnew is for allocating
runtime data structures and should never ask for an inappropriate
amount of memory.
With panicstring gone, delete newErrorCString, errorCString.
While we're here, delete newErrorString, not called by anyone.
(It can't be: that would be C code calling Go code that might
block or grow the stack.)
Found while debugging a malloc corruption.
This resulted in 'panic during panic' instead of a more useful message.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/138290045
It fails about 25% of the time on OS X.
I don't know what it's trying to do.
Created issue 8764 to correct this, but for now disable.
LGTM=bradfitz, mikioh.mikioh
R=bradfitz, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/144070044
Converting an integer to an interface{} allocates as of CL 130240043.
Fixes#8617.
LGTM=r
R=r
CC=golang-codereviews, khr
https://golang.org/cl/141700043
It is left from the time when Value was implemented in assembly.
Now it is implemented in Go and race detector understands Go.
In particular the atomic operations must provide
all necessary synchronization.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews, khr, rsc
https://golang.org/cl/145880043
We could probably free the G structures as well, but
for the allg list. Leaving that for another day.
Fixes#8287
LGTM=rsc
R=golang-codereviews, dvyukov, khr, rsc
CC=golang-codereviews
https://golang.org/cl/145010043
The logic here is copied from mgc0.c's scanframe.
Mostly it is messages although the minsize code is new
(and I believe necessary).
I am hoping to get more information about the current
arm build failures (or, if it's the minsize thing, fix them).
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/143180043
