Compiling with LTO revealed a number of cases in the runtime and
standard library where C and Go disagreed about the type of an object or
function (or where Go and code generated by the compiler disagreed). In
all cases the underlying representation was the same (e.g., uintptr vs.
void*), so this wasn't causing actual problems, but it did result in a
number of annoying warnings when compiling with LTO.
Reviewed-on: https://go-review.googlesource.com/c/160700
From-SVN: r268923
PR go/89168
libgo: change gotest to run examples with output
Change the gotest script to act like "go test" and run examples that
have "output" comments. This is not done with full generality, but
just enough to run the libgo tests. Other packages should be tested
with "go test" as usual.
While we're here clean up some old bits of gotest, and only run
TestXXX functions that are actually in *_test.go files. The latter
change should fix https://gcc.gnu.org/PR89168.
Reviewed-on: https://go-review.googlesource.com/c/162139
From-SVN: r268922
GCC has supported the __atomic intrinsics since 4.7. They are better
than the __sync intrinsics in that they specify a memory model and,
more importantly for our purposes, they are reliably implemented
either in the compiler or in libatomic.
Fixes https://gcc.gnu.org/PR52084
Reviewed-on: https://go-review.googlesource.com/c/160820
From-SVN: r268458
If sigtramp and sigtrampgo are both on stack, n -= framesToDiscard
is executed twice, which should actually run only once.
Reviewed-on: https://go-review.googlesource.com/c/159238
From-SVN: r268366
If a panic happens in the runtime we turn that into a fatal error.
We use the caller's PC to determine if the panic call is inside
the runtime. getcallerpc returns the PC immediately after the
call instruction. If the call is the very last instruction of a
function, it may not find this PC belong to a runtime function,
giving false result. We need to back off the PC by 1 to the call
instruction.
The gc runtime doesn't do this because the gc compiler always
emit an instruction following a panic call, presumably an UNDEF
instruction which turns into an architecture-specific illegal
instruction. Our compiler doesn't do this.
Reviewed-on: https://go-review.googlesource.com/c/159437
From-SVN: r268358
Precise stack scan uses SIGURG to trigger a stack scan. We need
to have Go signal handler installed for SIGURG.
Reviewed-on: https://go-review.googlesource.com/c/159097
From-SVN: r268230
PR go/88927
runtime, internal/cpu: fix build for ARM GNU/Linux
Was failing with
../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit'
138 | doinit()
| ^
Fix it by adding in Go 1.12 internal/cpu/cpu_arm.go, and the code in
runtime that initializes the values.
Fixes https://gcc.gnu.org/PR88927.
Reviewed-on: https://go-review.googlesource.com/c/158717
From-SVN: r268131
Restore some of the fixes that were applied to golang_org/x/net/lif
but were lost when 1.12 moved the directory to internal/x/net/lif.
Add support for reading /proc to fetch argc/argv/env for c-archive mode.
Reviewed-on: https://go-review.googlesource.com/c/158640
From-SVN: r268130
Reviewed-on: https://go-review.googlesource.com/c/158019
gotools/:
* Makefile.am (go_cmd_vet_files): Update for Go1.12beta2 release.
(GOTOOLS_TEST_TIMEOUT): Increase to 600.
(check-runtime): Export LD_LIBRARY_PATH before computing GOARCH
and GOOS.
(check-vet): Copy golang.org/x/tools into check-vet-dir.
* Makefile.in: Regenerate.
gcc/testsuite/:
* go.go-torture/execute/names-1.go: Stop using debug/xcoff, which
is no longer externally visible.
From-SVN: r268084
Currently, we dropg (which clears gp.m) after we CAS the g status
to _Grunnable or _Gwaiting. Immediately after CASing the g status,
another thread may CAS it to _Gscan status and scan its stack.
With precise stack scan, it accesses gp.m in order to switch to g
and back (in doscanstackswitch). This races with dropg. If
doscanstackswitch reads gp.m, then dropg runs, when we restore
the m at the end of the scan it will set to a stale value. Worse,
if dropg runs after doscanstackswitch sets the new m, gp will be
running with a nil m.
To fix this, we do dropg before CAS g status to _Grunnable or
_Gwaiting. We can do this safely if we are CASing from _Grunning,
as we own the g when it is in _Grunning. There is one case where
we CAS from _Gsyscall to _Grunnable. It is not safe to dropg when
it is in _Gsyscall, as precise stack scan needs to read gp.m in
order to signal the m. So we need to introduce a transient state,
_Gexitingsyscall, between _Gsyscall and _Grunnable, where the GC
should not scan its stack.
In is a little unfortunate that we have to add another g status.
We could reuse an existing one (e.g. _Gcopystack), but it is
clearer and safer to just use a new one, as Austin suggested.
Reviewed-on: https://go-review.googlesource.com/c/158157
From-SVN: r268001
CL 157557 changes the compiler to add one byte padding to
non-empty struct ending with a zero-sized field. Add the same
padding to the FFI type, so reflect.Call works.
This fixes test/fixedbugs/issue26335.go in the main repo.
Reviewed-on: https://go-review.googlesource.com/c/158018
From-SVN: r267956
This ports https://golang.org/cl/155918 from the master repo.
runtime: panic on uncomparable map key, even if map is empty
Reorg map flags a bit so we don't need any extra space for the extra flag.
This is a pre-req for updating libgo to the Go 1.12beta2 release.
Reviewed-on: https://go-review.googlesource.com/c/157858
From-SVN: r267950
This is the gccgo version of https://golang.org/cl/141822:
Only return a pointer p to the new slices backing array from makeslice.
Makeslice callers then construct sliceheader{p, len, cap} explictly
instead of makeslice returning the slice.
This change caused the GCC backend to break the runtime/pprof test by
merging together the identical functions allocateReflectTransient and
allocateTransient2M. This caused the traceback to be other than
expected. Fix that by making the functions not identical.
This is a step toward updating libgo to the Go1.12beta1 release.
Reviewed-on: https://go-review.googlesource.com/c/155937
From-SVN: r267660
Currently, when collecting a traceback for another goroutine,
getTraceback calls gogo(gp) switching to gp, which will resume in
mcall, which will call gtraceback, which will set up gp->m. There
is a gap between setting the current running g to gp and setting
gp->m. If a profiling signal arrives in between, sigtramp will
see a non-nil gp with a nil m, and will seg fault. Fix this by
setting up gp->m first.
Fixesgolang/go#29448.
Reviewed-on: https://go-review.googlesource.com/c/156038
From-SVN: r267658
This CL adds support of precise stack scan using stack maps to
the runtime. The stack maps are generated by the compiler (if
supported). Each safepoint is associated with a (real or dummy)
landing pad, and its "type info" in the exception table is a
pointer to the stack map. When a stack is scanned, the stack map
is found by the stack unwinding code by inspecting the exception
table (LSDA).
For precise stack scan we need to unwind the stack. There are
three cases:
- If a goroutine is scanning its own stack, it can unwind the
stack and scan the frames.
- If a goroutine is scanning another, stopped, goroutine, it
cannot directly unwind the target stack. We handle this by
switching (runtime.gogo) to the target g, letting it unwind
and scan the stack, and switch back.
- If we are scanning a goroutine that is blocked in a syscall,
we send a signal to the target goroutine's thread, and let the
signal handler unwind and scan the stack. Extra care is needed
as this races with enter/exit syscall.
Currently this is only implemented on linux.
Reviewed-on: https://go-review.googlesource.com/c/140518
From-SVN: r266832
The current implementation of Gogo::pkgpath_for_symbol was written in
a way that allowed two distinct package paths to map to the same
symbol, which could cause collisions at link- time or compile-time.
Switch to a better mangling scheme to insure that we get a unique
packagepath symbol for each package. In the new scheme instead of having
separate mangling schemes for identifiers and package paths, the
main identifier mangler ("go_encode_id") now handles mangling of
both packagepath characters and identifier characters.
The new mangling scheme is more intrusive: "foo/bar.Baz" is mangled as
"foo..z2fbar.Baz" instead of "foo_bar.Baz". To mitigate this, this
patch also adds a demangling capability so that function names
returned from runtime.CallersFrames are converted back to their
original unmangled form.
Changing the pkgpath_for_symbol scheme requires updating a number of
//go:linkname directives and C "__asm__" directives to match the new
scheme, as well as updating the 'gotest' driver (which makes
assumptions about the correct mapping from pkgpath symbol to package
name).
Fixesgolang/go#27534.
Reviewed-on: https://go-review.googlesource.com/c/135455
From-SVN: r265510
PR go/87661
runtime: remove unused armArch, hwcap and hardDiv
After CL 140057 these are only written but never read in gccgo.
Reviewed-on: https://go-review.googlesource.com/c/141077
From-SVN: r265439
LLVM doesn't support non-call exception. This test was passing
more or less by luck: if the faulting instruction is between two
calls with the same landing pad (in instruction layout order,
not the program's logic order), it generates a merged PC range
that covers the faulting instruction. If the instruction layout
order changes, or it uses two different (but may be degenerate)
landing pads, this doesn't work.
Reviewed-on: https://go-review.googlesource.com/c/140517
From-SVN: r264985
This is enough to let libgo build when configured using
--with-multilib-list=m64,m32,mx32. I don't have an x32-enabled kernel
so I haven't tested whether it executes correctly.
For https://gcc.gnu.org/PR87470
Reviewed-on: https://go-review.googlesource.com/138817
From-SVN: r264772
Reviewed-on: https://go-review.googlesource.com/136435
gotools/:
* Makefile.am (mostlyclean-local): Run chmod on check-go-dir to
make sure it is writable.
(check-go-tools): Likewise.
(check-vet): Copy internal/objabi to check-vet-dir.
* Makefile.in: Rebuild.
From-SVN: r264546
In 1.11 writebarrierptr is going away, so change the compiler to call
gcWriteBarrier instead. We weren't using gcWriteBarrier before;
adjust the implementation to use the putFast method.
This revealed a problem in the kickoff function. When using cgo,
kickoff can be called on the g0 of an m allocated by newExtraM. In
that case the m will generally have a p, but systemstack may be called
by wbBufFlush as part of flushing the write barrier buffer. At that
point the buffer is full, so we can not do a write barrier. So adjust
the existing code in kickoff so that in the case where we are g0,
don't do any write barrier at all.
Reviewed-on: https://go-review.googlesource.com/131395
From-SVN: r264295
In the sweep code we can sometimes see incorrect counts when
conservative stack scanning causes us to grey an object that we
earlier decided could be freed. We already ignored this check, but
adjust this case to maintain correct span counts when it happens.
This gives us slightly more correct numbers in MemStats, and helps
avoid a rare failure in TestReadMemStats.
Also fix the free index, and cope with finding a full span when
allocating a new one.
Reviewed-on: https://go-review.googlesource.com/134216
From-SVN: r264294
Unlike the gc runtime, libgo stores traceback information in location
structs, which contain strings. Therefore, copying location structs
around appears to require write barriers, although in fact write
barriers are never important because the strings are never allocated
in Go memory. They come from libbacktrace.
Some of the generated write barriers come at times when write barriers
are not permitted. For example, exitsyscall, marked
nowritebarrierrec, calls exitsyscallfast which calls traceGoSysExit
which calls traceEvent which calls traceStackID which calls
trace.stackTab.put which copies location values into memory allocated
by tab.newStack. This write barrier can be invoked when there is no
p, causing a crash.
This change fixes the problem by ensuring that location values are
copied around in the tracing code with no write barriers.
This was found by fixing the compiler to fully implement
//go:nowritebarrierrec; CL to follow.
Reviewed-on: https://go-review.googlesource.com/134226
From-SVN: r264282
To reduce the amount of time spent in write barrier processing
(specifically runtime.bulkBarrierPreWrite), add support for building a
'GC roots index', basically a sorted list of all roots, so as to
allow more efficient lookups of gcdata structures for globals. The
previous implementation worked on the raw (unsorted) roots list
itself, which did not scale well.
Reviewed-on: https://go-review.googlesource.com/132595
From-SVN: r264276
This is the gofrontend version of https://golang.org/cl/91796.
This is part of that CL, just the compiler change and required runtime
changes, in preparation for updating libgo to 1.11.
Relevant part of original CL description:
The hmap field in the maptype is only used by the runtime to check the sizes of
the hmap structure created by the compiler and runtime agree.
Comments are already present about the hmap structure definitions in the
compiler and runtime needing to be in sync.
Reviewed-on: https://go-review.googlesource.com/130976
From-SVN: r263941
This is a port of https://golang.org/cl/109596 to the gofrontend, in
preparation for updating libgo to 1.11.
Original CL description:
getcallersp is intrinsified, and so the dummy arg is no longer
needed. Remove it, as well as a few dummy args that are solely
to feed getcallersp.
Reviewed-on: https://go-review.googlesource.com/131116
From-SVN: r263840
When writing stack frames to the pprof CPU profile machinery, it is
very important to insure that the frames emitted do not contain any
frames corresponding to artifacts of the profiling process itself
(signal handlers, sigprof, etc). This patch changes runtime.sigprof to
strip out those frames from the raw stack generated by
"runtime.callers".
Fixesgolang/go#26595.
Reviewed-on: https://go-review.googlesource.com/126175
From-SVN: r263035
The libffi library doesn't understand zero-sized objects.
When we see a zero-sized field in a struct, just skip it when
converting to the FFI data structures. There is no value to pass in
any case, so not telling libffi about the field doesn't affect
anything.
The test case for this is https://golang.org/cl/123316.
Fixesgolang/go#26335
Reviewed-on: https://go-review.googlesource.com/123335
From-SVN: r262651
We're never going to use stack.go for gccgo. Although a build tag
keeps it from being built, even having it around can be confusing.
Remove it.
Reviewed-on: https://go-review.googlesource.com/40774
From-SVN: r259865
The gccgo runtime is never stale, and on a system with gc sources in
~/go the test may wind up checking whether the gc runtime is stale.
Reviewed-on: https://go-review.googlesource.com/102282
From-SVN: r258865
PR go/84484
libgo: add support for riscv64
Patch by Andreas Schwab.
Reviewed-on: https://go-review.googlesource.com/96377
* go.test/go-test.exp (go-set-goarch): Recognize riscv64-*-*.
From-SVN: r257914
Let a fast syscall return be a preemption point. This helps with
tight loops that make system calls, as in BenchmarkSyscallExcessWork.
Reviewed-on: https://go-review.googlesource.com/94895
From-SVN: r257848
Long long long ago Go permitted writing
func F()
in one file and writing
func F() {}
in another file. This was removed from the language, and that is now
considered to be a multiple definition error. Gccgo never caught up
to that, and it has been permitting this invalid code for some time.
Stop permitting it, so that we give correct errors. Since we've
supported it for a long time, the compiler uses it in a couple of
cases: it predeclares the hash/equal methods if it decides to create
them while compiling another function, and it predeclares main.main as
a mechanism for getting the right warning if a program uses the wrong
signature for main. For simplicity, keep those existing uses.
This required a few minor changes in libgo which were relying,
unnecessarily, on the current behavior.
Reviewed-on: https://go-review.googlesource.com/93083
From-SVN: r257600
PR go/84215
runtime, sync/atomic: use write barrier for atomic pointer functions
This copies atomic_pointer.go from 1.10rc2. It was omitted during the
transition of the runtime from C to Go, and I forgot about it.
This may help with https://gcc.gnu.org/PR84215.
Reviewed-on: https://go-review.googlesource.com/93197
From-SVN: r257599
