aboutsummaryrefslogtreecommitdiff
path: root/libgo/go/runtime/proc.go
AgeCommit message (Collapse)AuthorFilesLines
2022-02-18libgo: update to Go1.18rc1 releaseIan Lance Taylor1-95/+48
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/386594
2022-02-11libgo: update to Go1.18beta2Ian Lance Taylor1-107/+64
gotools/ * Makefile.am (go_cmd_cgo_files): Add ast_go118.go (check-go-tool): Copy golang.org/x/tools directories. * Makefile.in: Regenerate. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384695
2022-02-08compiler, internal/abi: implement FuncPCABI0, FuncPCABIInternalIan Lance Taylor1-5/+6
The Go 1.18 standard library uses an internal/abi package with two functions that are implemented in the compiler. This patch implements them in the gofrontend, to support the upcoming update to 1.18. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/383514
2021-08-12libgo: update to Go1.17rc2Ian Lance Taylor1-310/+484
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/341629
2021-06-10libgo: update to Go1.16.5 releaseIan Lance Taylor1-0/+26
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/326772
2021-01-29libgo: update to Go1.16rc1Ian Lance Taylor1-9/+70
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/287493
2020-12-30libgo: update to Go1.16beta1 releaseIan Lance Taylor1-170/+607
This does not yet include support for the //go:embed directive added in this release. * Makefile.am (check-runtime): Don't create check-runtime-dir. (mostlyclean-local): Don't remove check-runtime-dir. (check-go-tool, check-vet): Copy in go.mod and modules.txt. (check-cgo-test, check-carchive-test): Add go.mod file. * Makefile.in: Regenerate. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/280172
2020-12-08libgo: update to 1.15.6 releaseIan Lance Taylor1-10/+16
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/276153
2020-11-20compiler, libgo: change mangling schemeIan Lance Taylor1-13/+13
Overhaul the mangling scheme to avoid ambiguities if the package path contains a dot. Instead of using dot both to separate components and to mangle characters, use dot only to separate components and use underscore to mangle characters. For golang/go#41862 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
2020-11-10libgo: update to Go 1.15.4 releaseIan Lance Taylor1-0/+21
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/268177
2020-08-07libgo: update to Go1.15rc2 releaseIan Lance Taylor1-17/+52
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/247517
2020-08-01libgo: update to go1.15rc1Ian Lance Taylor1-58/+212
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/245157
2020-07-10libgo: update to Go 1.14.4 releaseIan Lance Taylor1-0/+6
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/241999
2020-02-15libgo: update to Go1.14rc1 releaseIan Lance Taylor1-58/+59
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/218017
2020-02-15runtime: on 32-bit systems, limit default GOMAXPROCS to 32Ian Lance Taylor1-0/+8
Otherwise we can easily run out of stack space for threads. The user can still override by setting GOMAXPROCS. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/219278
2020-01-21libgo: update to Go1.14beta1Ian Lance Taylor1-272/+375
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/214297
2020-01-07compiler, runtime: stop using __go_runtime_errorIan Lance Taylor1-0/+8
Use specific panic functions instead, which are mostly already in the runtime package. Also correct "defer nil" to panic when we execute the defer, rather than throw when we queue it. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/213642 From-SVN: r279979
2019-09-12libgo: update to Go1.13Ian Lance Taylor1-7/+0
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/194698 From-SVN: r275691
2019-09-06libgo: update to Go 1.13beta1 releaseIan Lance Taylor1-143/+177
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/193497 From-SVN: r275473
2019-08-31compiler, runtime: support and use single argument go:linknameIan Lance Taylor1-27/+27
The gc compiler has started permitting go:linkname comments with a single argument to mean that a function should be externally visible outside the package. Implement this in the Go frontend. Change the libgo runtime package to use it, rather than repeating the name just to export a function. Remove a couple of unnecessary go:linkname comments on declarations. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/192197 From-SVN: r275239
2019-05-11runtime: set up g earlyIan Lance Taylor1-7/+11
runtime.throw needs a g to work properly. Set up g early, to ensure that if something goes wrong in the runtime startup (e.g. runtime.check fails), the program terminates in a reasonable way. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/176657 From-SVN: r271088
2019-05-01compiler,runtime: do more direct interfacesIan Lance Taylor1-1/+1
A direct interface is an interface whose data word contains the actual data value, instead of a pointer to it. The gc toolchain creates a direct interface if the value is pointer shaped, that includes pointers (including unsafe.Pointer), functions, channels, maps, and structs and arrays containing a single pointer-shaped field. In gccgo, we only do this for pointers. This CL unifies direct interface types with gc. This reduces allocations when converting such types to interfaces. Our method functions used to always take pointer receivers, to make interface calls easy. Now for direct interface types, their value methods will take value receivers. For a pointer to those types, when converted to interface, the interface data contains the pointer. For that interface to call a value method, it will need a wrapper method that dereference the pointer and invokes the value method. The wrapper method, instead of the actual one, is put into the itable of the pointer type. In the runtime, adjust funcPC for the new layout of interfaces of functions. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/168409 From-SVN: r270779
2019-02-27re PR go/89172 (FAIL: runtime/pprof)Ian Lance Taylor1-1/+8
PR go/89172 internal/cpu, runtime, runtime/pprof: handle function descriptors When using PPC64 ELF ABI v1 a function address is not a PC, but is the address of a function descriptor. The first field in the function descriptor is the actual PC (see http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES). The libbacktrace library knows about this, and libgo uses actual PC values consistently except for the helper function funcPC that appears in both runtime and runtime/pprof. This patch fixes funcPC by recording, in the internal/cpu package, whether function descriptors are being used. We have to check for function descriptors using a C compiler check, because GCC can be configured using --with-abi to select the ELF ABI to use. Fixes https://gcc.gnu.org/PR89172 Reviewed-on: https://go-review.googlesource.com/c/162978 From-SVN: r269266
2019-02-19runtime: abort stack scan in cases that we cannot unwind the stackIan Lance Taylor1-0/+3
In signal-triggered stack scan, if the signal is delivered at certain bad time (e.g. in vdso, or in the middle of setcontext?), the unwinder may not be able to unwind the whole stack, while it still reports _URC_END_OF_STACK. So we cannot rely on _URC_END_OF_STACK to tell if it successfully scanned the stack. Instead, we check the last Go frame to see it actually reached the end of the stack. For Go-created stack, this is runtime.kickoff. For C-created stack, we need to record the outermost Go frame when it enters the Go side. Also we cannot unwind the stack if the signal is delivered in the middle of runtime.gogo, halfway through a goroutine switch, where the g and the stack don't match. Give up in this case as well. Reviewed-on: https://go-review.googlesource.com/c/159098 From-SVN: r269018
2019-02-15compiler, runtime: harmonize types referenced by both C and GoIan Lance Taylor1-1/+1
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
2019-01-29runtime: fix sigprof frame countingIan Lance Taylor1-2/+1
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
2019-01-18libgo: update to Go1.12beta2Ian Lance Taylor1-241/+299
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
2019-01-18re PR go/88202 (FAIL: runtime/pprof)Ian Lance Taylor1-2/+9
PR go/88202 runtime: in sigprof, skip to sigtrampgo if we don't find sigtramp Fixes https://gcc.gnu.org/PR88202 Reviewed-on: https://go-review.googlesource.com/c/158218 From-SVN: r268057
2019-01-17runtime: dropg before CAS g status to _Grunnable/_GwaitingIan Lance Taylor1-3/+8
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
2018-12-05runtime: add precise stack scan supportIan Lance Taylor1-1/+50
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
2018-10-25compiler: improve name mangling for packpathsIan Lance Taylor1-3/+3
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). Fixes golang/go#27534. Reviewed-on: https://go-review.googlesource.com/c/135455 From-SVN: r265510
2018-09-24libgo: update to Go 1.11Ian Lance Taylor1-29/+147
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
2018-09-13compiler, runtime: call gcWriteBarrier instead of writebarrierptrIan Lance Taylor1-15/+20
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
2018-09-13runtime: avoid write barriers with traceback infoIan Lance Taylor1-2/+2
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
2018-09-13libgo: build roots index to speed up bulkBarrierPreWriteIan Lance Taylor1-0/+1
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
2018-08-24runtime: remove the dummy arg of getcallerspIan Lance Taylor1-4/+4
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
2018-07-27libgo: prune sighandler frames in runtime.sigprofIan Lance Taylor1-1/+29
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". Fixes golang/go#26595. Reviewed-on: https://go-review.googlesource.com/126175 From-SVN: r263035
2018-05-31libgo: update to Go 1.10.2 releaseIan Lance Taylor1-0/+6
Reviewed-on: https://go-review.googlesource.com/115196 From-SVN: r261041
2018-02-20runtime: allow preemption in fast syscall returnIan Lance Taylor1-0/+7
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
2018-02-16runtime: add some more preemption checksIan Lance Taylor1-2/+3
In particular this lets BenchmarkPingPongHog in runtime/proc_test.go complete. Reviewed-on: https://go-review.googlesource.com/94735 From-SVN: r257743
2018-02-07runtime: don't call funcPC from a functionIan Lance Taylor1-1/+3
The escape analysis support is not yet good enough to avoid escaping the argument to funcPC. This causes unnecessary and often harmful memory allocation. E.g., (*cpuProfile).addExtra can be called from a signal handler, and it must not allocate memory. Move the calls to funcPC to use variables instead. This was done in the original migration to using funcPC, but was not done for newer code. In one case, in signal handling code, use getSigtramp. Reviewed-on: https://go-review.googlesource.com/92735 From-SVN: r257463
2018-01-17libgo: update to Go1.10beta2 releaseIan Lance Taylor1-1/+7
Reviewed-on: https://go-review.googlesource.com/87897 From-SVN: r256794
2018-01-10runtime: noescape some functions/variablesIan Lance Taylor1-0/+4
This is in preparation of turning on escape analysis for the runtime. - In gccgo, systemstack is implemented with mcall, which is not go:noescape. Wrap the closure in noescape so the escape analysis does not think it escapes. - Mark some C functions go:noescape. They do not leak arguments. - Use noescape function to make a few local variables' addresses not escape. The escape analysis cannot figure out because they are assigned to pointer indirections. Reviewed-on: https://go-review.googlesource.com/86244 From-SVN: r256418
2018-01-09libgo: update to Go1.10beta1Ian Lance Taylor1-141/+500
Update the Go library to the 1.10beta1 release. Requires a few changes to the compiler for modifications to the map runtime code, and to handle some nowritebarrier cases in the runtime. Reviewed-on: https://go-review.googlesource.com/86455 gotools/: * Makefile.am (go_cmd_vet_files): New variable. (go_cmd_buildid_files, go_cmd_test2json_files): New variables. (s-zdefaultcc): Change from constants to functions. (noinst_PROGRAMS): Add vet, buildid, and test2json. (cgo$(EXEEXT)): Link against $(LIBGOTOOL). (vet$(EXEEXT)): New target. (buildid$(EXEEXT)): New target. (test2json$(EXEEXT)): New target. (install-exec-local): Install all $(noinst_PROGRAMS). (uninstall-local): Uninstasll all $(noinst_PROGRAMS). (check-go-tool): Depend on $(noinst_PROGRAMS). Copy down objabi.go. (check-runtime): Depend on $(noinst_PROGRAMS). (check-cgo-test, check-carchive-test): Likewise. (check-vet): New target. (check): Depend on check-vet. Look at cmd_vet-testlog. (.PHONY): Add check-vet. * Makefile.in: Rebuild. From-SVN: r256365
2017-09-14libgo: update to go1.9Ian Lance Taylor1-91/+203
Reviewed-on: https://go-review.googlesource.com/63753 From-SVN: r252767
2017-06-23runtime: don't crash if no p in kickoffIan Lance Taylor1-0/+18
The kickoff function for g0 can be invoked without a p, for example from mcall(exitsyscall0) in exitsyscall after exitsyscall has cleared the p field. The assignment gp.param = nil will invoke a write barrier. If gp.param is not already nil, this will require a p. Avoid the problem for a specific case that is known to be OK: when the value in gp.param is a *g. Reviewed-on: https://go-review.googlesource.com/46512 From-SVN: r249595
2017-06-22runtime: mark dropm and callees nowritebarrierrecIan Lance Taylor1-0/+5
The CgocallbackDone function calls dropm after it calls entersyscall, which means that dropm must not have any write barriers. Mark it accordingly. Reviewed-on: https://go-review.googlesource.com/46464 From-SVN: r249577
2017-06-22runtime: export getm functionIan Lance Taylor1-0/+3
Use go:linkname to export the getm function. This makes it visible to runtime/testdata/testprogcgo/dropm_stub.go, which uses it as part of the TestEnsureDropM test in runtime/crash_cgo_test.go. That test is not run today, but it will be soon. Reviewed-on: https://go-review.googlesource.com/46462 From-SVN: r249576
2017-06-22runtime: make NumGoroutine wait for system goroutines to registerIan Lance Taylor1-0/+24
In libgo system goroutines register themselves after they start. That means that there is a small race between the goroutine being seen by the scheduler and the scheduler knowing that the goroutine is a system goroutine. That in turn means that runtime.NumGoroutines can overestimate the number of goroutines at times. This patch fixes the overestimate by counting the number of system goroutines waiting to start, and pausing NumGoroutines until those goroutines have all registered. This is kind of a lot of mechanism for this not very important problem, but I couldn't think of a better approach. The test for this is TestNumGoroutine in runtime/proc_test.go. The test is not currently run, but it will be soon. Reviewed-on: https://go-review.googlesource.com/46457 From-SVN: r249565
2017-06-22runtime: change some stack fields to uintptrIan Lance Taylor1-4/+4
Because of how gccgo implements cgo calls, the code in dropm may not have any write barriers. As a step toward implementing that, change the gcstack, gcnextsegment, and gcnextsp fields of the g struct to uintptr, so that assignments to them do not require write barriers. The gcinitialsp field remains unsafe.Pointer, as on 32-bit systems that do not support split stack it points to a heap allocated space used for the goroutine stack. The test for this is runtime tests like TestCgoCallbackGC, which are not run today but will be run with a future gotools patch. Reviewed-on: https://go-review.googlesource.com/46396 From-SVN: r249561