cmd/go: make malformed import path message more precise
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
cmd/go: re-resolve and check vcs roots during go get -u
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
Keith Randall [Thu, 25 Sep 2014 14:59:01 +0000 (07:59 -0700)]
cgo: adjust return value location to account for stack copies.
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.
Rob Pike [Wed, 24 Sep 2014 21:33:30 +0000 (14:33 -0700)]
fmt: document and fix the handling of precision for strings and byte slices
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.
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...
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.
runtime: keep g->syscallsp consistent after cgo->Go callbacks
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.
Rob Pike [Wed, 24 Sep 2014 01:24:35 +0000 (18:24 -0700)]
cmd/pack: fix c command for existing file
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.
Rob Pike [Mon, 22 Sep 2014 18:46:02 +0000 (11:46 -0700)]
text/template: allow comparison functions to work between any integers
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?
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.
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.
Dave Cheney [Fri, 19 Sep 2014 02:02:21 +0000 (02:02 +0000)]
runtime: fix GOARM<7 build
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.
Alex Brainman [Fri, 19 Sep 2014 01:38:48 +0000 (11:38 +1000)]
runtime: allow OutputDebugString to be sent to debugger
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.
runtime: show frames for exported runtime functions
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.
Ian Lance Taylor [Fri, 19 Sep 2014 00:27:26 +0000 (17:27 -0700)]
lib9, cmd/ld: fixes for cross-linking on a Windows host
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.
runtime: delete panicstring; move its checks into gopanic
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.
sync/atomic: remove unnecessary race instrumentation in Value
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.