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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
