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
The quoting code that read _cgo_flags, currently only in the gccgo
version of cmd/go, was losing the last flag read from the file.
Fixesgolang/go#23666
Reviewed-on: https://go-review.googlesource.com/91655
From-SVN: r257373
They were disabled due to the lack of escape analysis. Now that
we have escape analysis, unskip these tests.
Reviewed-on: https://go-review.googlesource.com/86248
From-SVN: r257324
On ia64, a separate stack is used for saving/restoring register frames,
occupying the other end of the stack mapping. This must also be scanned
for pointers into the heap.
Reviewed-on: https://go-review.googlesource.com/85276
From-SVN: r257323
We were using special compilation flags for the math package, but we
weren't using them when testing. That meant that our tests were not
checking the real code we were providing. Fix that.
Fixing that revealed that we were not using a good set of flags, or at
least were not using flags that let the tests pass. Adjust the flags
to stop using -funsafe-math-optimizations on x86. Instead always use
-ffp-contract=off -fno-math-errno -fno-trapping-math for all targets.
Fixesgolang/go#23647
Reviewed-on: https://go-review.googlesource.com/91355
From-SVN: r257312
Otherwise on a 64-bit system we will read the 32-bit value as a 64-bit
value. Since getaddrinfo returns negative numbers as error values,
these will be interpreted as numbers like 0xfffffffe rather than -2,
and the comparisons with values like syscall.EAI_NONAME will fail.
Fixesgolang/go#23645
Reviewed-on: https://go-review.googlesource.com/91296
From-SVN: r257299
On ppc64 gotest treats data variables whose names begin with "Test" as
tests to run. This is to support the function descriptors used for
ppc64 ELF ABI v1. This causes gotest to think that TestAddr6 is a
test, when it is actually a variable. For a simple fix until we can
figure out how to write gotest properly, rename the variable.
Fixesgolang/go#23623
Reviewed-on: https://go-review.googlesource.com/90995
From-SVN: r257235
CL 84555 added support for the SuperH architecture, but didn't add the
randomTrap definition to be used for the getrandom syscall on Linux.
Add it now.
Reviewed-on: https://go-review.googlesource.com/90535
From-SVN: r257171
This was the original intent, as reflected in the long comment at the
start of names.cc, but I forgot to implement it.
Also, remove a leading ".0" from the final name. That could occur for
a method whose receiver type starts with 'u', as in that case we
prepend a space to the mangled name, to avoid confusion with the
Unicode mangling, and the space turns into ".0".
Also, if the Unicode encoding would cause the final to start with
"..u" or "..U", add a leading underscore.
Patch gotest to not get fooled by some names.
The result of these changes is that all symbols start with a letter or
an underscore.
Reviewed-on: https://go-review.googlesource.com/90015
From-SVN: r257068
The top three region number bits must be masked out before
right-shifting the address bits into place, otherwise they will be
copied down into the lower always-zero address bits.
Reviewed-on: https://go-review.googlesource.com/84535
From-SVN: r257061
Encode all external symbol names using only ASCII alphanumeric
characters, underscore, and dot. Use a scheme that can be reliably
demangled to a somewhat readable version as described in the long
comment in names.cc.
A minor cleanup discovered during this was that we were treating
function types as different if one had a NULL parameters_ field and
another has a non-NULL parameters_ field that has no parameters. This
worked because we mangled them slightly differently. We now mangle
them the same, so we treat them as equal, as we should anyhow.
Reviewed-on: https://go-review.googlesource.com/89555
* go.go-torture/execute/names-1.go: New test.
From-SVN: r257033
PR go/83787
compiler: pass int to makechan, call makechan64 when appropriate
The update to 1.10beta1 changed makechan to take int instead of int64,
and added a makechan64 call for large values. Since the size is the
last argument to makechan, the old compiler which always passed a
64-bit int worked fine on 64-bit systems and little-endian 32-bit
systems, but broke on big-endian 32-bit systems. This CL fixes the
compiler to use the appropriate types.
This fixes GCC PR 83787.
Reviewed-on: https://go-review.googlesource.com/88077
From-SVN: r256835
Move the architecture-specific settings out of configure.ac into a new
shell script goarch.sh. Use the new script to collect the values for
all architectures to make them available in go/types.
Also fix cmd/vet to pass the right compiler when it calls SizesFor.
This fixes cmd/vet for systems that are not implemented in the gc
toolchain, such as alpha and ia64.
Reviewed-on: https://go-review.googlesource.com/87635
From-SVN: r256655
Add missing .a files. These should have been committed with the
update to go1.10beta1, but were skipped because by default Subversion
ignores all files matching *.a.
From-SVN: r256442
PR c/82922
runtime, syscall: use full prototypes in C code
Based on patch by Martin Sebor.
Reviewed-on: https://go-review.googlesource.com/86815
From-SVN: r256437
GCC always recognizes the -fsplit-stack option, but then tests whether
it is supported by the selected target. If not, it reports
cc1: error: ‘-fsplit-stack’ is not supported by this compiler configuration
Check for that error message when deciding whether a compiler option works.
Reviewed-on: https://go-review.googlesource.com/87137
From-SVN: r256433
When compiling runtime, it is not allowed for local variables
and closures to be heap allocated. In one test, there is a go
statement with a closure. In the gc compiler, it distinguishes
capturing variable by value vs. by address, and rewrites it to
passing the captured values as arguments. Currently we don't
have this, and the escape analysis decides to heap allocate the
closure and also the captured variables, which is not allowed.
Work around it by passing the variables explicitly.
This is in preparation of turning on escape analysis for the
runtime.
Reviewed-on: https://go-review.googlesource.com/86245
From-SVN: r256419
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 functions cgoCheckPointer and cgoCheckResult are called by code
generated by cgo. That means that we need to export them using
go:linkname, as otherwise they are local symbols. The cgo code
currently uses weak references to only call the symbols if they are
defined, which is why it has been working--the cgo code has not been
doing any checks.
Reviewed-on: https://go-review.googlesource.com/80295
From-SVN: r255347
For a misaligned address force a panic rather than assuming that reading
from the address 0 will cause one.
Reviewed-on: https://go-review.googlesource.com/69850
From-SVN: r254610
Also fix 64-bit DWARF to read a 64-bit abbrev offset in the
compilation unit.
This is a backport of https://golang.org/cl/71171, which will be in
the Go 1.10 release, to the gofrontend copy. Doing it now because AIX
is pretty much the only system that uses 64-bit DWARF.
Reviewed-on: https://go-review.googlesource.com/72250
From-SVN: r253955
In preparation for upgrading libgo to the 1.9 release, this
approximately incorporates https://golang.org/cl/37661 and
https://golang.org/cl/38351.
CL 37661 changed the gc compiler such that the select statement simply
returns an integer which is then used as the argument for a switch.
Since gccgo already worked that way, this just adjusts the switch code
to look like the gc switch code by removing the explicit case index
expression and calculating it from the order of calls to selectsend,
selectrecv, and selectdefault.
CL 38351 simplifies the channel code by not passing the unused channel
type descriptor pointer.
Reviewed-on: https://go-review.googlesource.com/62730
From-SVN: r252749
This adds much of https://golang.org/cl/35731 and
https://golang.org/cl/35732 to the gofrontend code.
This is a step toward updating libgo to the 1.9 release. The
gofrontend already supports type aliases, and this is required for
correct support of type aliases when used as embedded fields.
The change to expressions.cc is to handle the << 1, used for the
newly renamed offsetAnon field, in the constant context used for type
descriptor initialization.
Reviewed-on: https://go-review.googlesource.com/62710
From-SVN: r252746
Using -funwind-tables is necessary to permit Go code to correctly
throw a panic through C code. This hasn't been necessary in the past
as -funwind-tables is the default on x86. However, it is not the
default for PPC AIX.
Reviewed-on: https://go-review.googlesource.com/56650
From-SVN: r251179
Libgo's implementation of math.Ldexp declared the libc "ldexp" as
taking an 'int' exponent argument, which is not quite right for 64-bit
platforms (exp arg is always int32); this could yield incorrect
results for exponent values outside the range of Minint32/Maxint32.
Fix by upating the type for the libc version of ldexp, and adding
guards to screen for out-of-range exponents.
Fixes#21323.
Reviewed-on: https://go-review.googlesource.com/54250
From-SVN: r250992
We unconditionally set _FILE_OFFSET_BITS to 64 in configure.ac, so we
should unconditionally call the statfs64 and fstatfs64 functions.
These functions should be available on all versions of GNU/Linux since 2.6.
On 64-bit systems they are aliased to statfs/fstatfs, and on 32-bit
systems they use the 64-bit data structures.
Fixesgolang/go#20922
Reviewed-on: https://go-review.googlesource.com/50635
From-SVN: r250443
Allocate enough stack space so that the test will work on a system
that does not support split stacks.
This test is actually not very meaningful for gccgo at present, but it
doesn't hurt to keep running it.
Updates golang/go#20931
Reviewed-on: https://go-review.googlesource.com/50630
From-SVN: r250433
PR go/81451
runtime: inline runtime_osinit
We had two identical copies of runtime_osinit. They set runtime_ncpu,
a variable that is no longer used. Removing that leaves us with two lines.
Inline those two lines in the two places the function was called.
This fixes GCC PR 81451.
Reviewed-on: https://go-review.googlesource.com/48862
From-SVN: r250326
PR go/81393
syscall: don't use GETREGS/SETREGS on s390
They were removed in recent glibc.
Patch by Andreas Krebbel for GCC PR 81393.
Reviewed-on: https://go-review.googlesource.com/48231
From-SVN: r250174
On AIX:
* mmap does not allow to map an already mapped range,
* mmap range start at 0x30000000 for 32 bits processes,
* mmap range start at 0x70000000_00000000 for 64 bits processes
This is adapted from change 37845.
Issue golang/go#19200
Reviewed-on: https://go-review.googlesource.com/46772
From-SVN: r249713
Fixes required now that we #include <linux/ptrace.h> in sysinfo.c.
Patch by Andreas Krebbel.
Reviewed-on: https://go-review.googlesource.com/46839
From-SVN: r249712
When C code calls a Go function, it actually calls a function
generated by cgo. That function is written in Go, and, among other
things, it calls the real Go function like this:
CgocallBack()
defer CgocallBackDone()
RealGoFunction()
The deferred CgocallBackDone function enters syscall mode as we return
to C. Typically the C function will then eventually return to Go.
However, in the case where the C function is running on a thread
created in C, it will not return to Go. For that case we will have
allocated an m struct, with an associated g struct, for the duration
of the Go code, and when the Go is complete we will return the m and g
to a free list.
That all works, but we are running in a deferred function, which means
that we have been invoked by deferreturn, and deferreturn expects to
do a bit of cleanup to record that the defer has been completed. Doing
that cleanup while using an m and g that have already been returned to
the free list is clearly a bad idea. It was kind of working because
deferreturn was holding the g pointer in a local variable, but there
were races with some other thread picking up and using the newly freed g.
It was also kind of working because of a special check in freedefer;
that check is no longer necessary.
This patch changes the special case of releasing the m and g to do the
defer cleanup in CgocallBackDone itself.
This patch also checks for the special case of a panic through
CgocallBackDone. In that special case, we don't want to release the m
and g. Since we are returning to C code that was not called by Go
code, we know that the panic is not going to be caught and we are
going to exit the program. So for that special case we keep the m and
g structs so that the rest of the panic code can use them.
Reviewed-on: https://go-review.googlesource.com/46530
From-SVN: r249611
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
When a panic occurs while processing a deferred function that
recovered an earlier panic, we shouldn't report the recovered panic
in the panic stack trace. Stop doing so by keeping track of the panic
that triggered a defer, marking it as aborted if we see the defer again,
and discarding aborted panics when a panic is recovered. This is what
the gc runtime does.
The test for this is TestRecursivePanic in runtime/crash_test.go.
We don't run that test yet, but we will soon.
Reviewed-on: https://go-review.googlesource.com/46461
From-SVN: r249590
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
With the gc toolchain apparently
var s *string
_ = *s
is enough to panic with a nil pointer dereference. The gccgo compiler
will simply discard the dereference, which I think is a reasonable and
acceptable optimization. Change the tests to use an exported variable
instead. The tests are not currently run, but they will be with a
later patch to gotools.
Reviewed-on: https://go-review.googlesource.com/46450
From-SVN: r249562
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
Calling a deferred function currently requires changing from a uintptr
to the function code to a Go function value. That is done by setting
the value of a func local variable using unsafe.Pointer. The local
variable will always be on the stack. Adjust the code that sets the
local variable to avoid generating a write barrier.
A write barrier is never needed here. Also, for deferreturn, we must
avoid write barriers entirely when called from a cgo function; that
requires more than just this, but this is a start.
The test for this is runtime tests that use the go tool; these are not
currently run, but they will be in the future.
Reviewed-on: https://go-review.googlesource.com/46455
From-SVN: r249559
The gc version of the _defer struct has a _panic field that has a
completely different meaning. We are going to want that bring that new
meaning into the gofrontend to improve panic reports with nested
panic calls. Simplify that by first renaming the existing _panic field.
Reviewed-on: https://go-review.googlesource.com/46454
From-SVN: r249558
- don't run tests that depend on SetCgoTraceback
- don't expect a '(' after the function name in a traceback
- change the expected name of nested functions in a traceback
These tests are not currently run, but they will be soon.
Reviewed-on: https://go-review.googlesource.com/46453
From-SVN: r249557
The gofrontend doesn't support the runtime.SetCgoTraceback function,
which is specifically for handling mixed Go and C tracebacks.
Use a build tag to avoid compiling the runtime/testdata/testprogcgo
files that refer to SetCgoTraceback. These files are not currently
compiled anyhow, but they will be with a future gotools patch.
Reviewed-on: https://go-review.googlesource.com/46452
From-SVN: r249556
Building this test with gccgo requires an explicit -pthread option to
be passed to the C compiler, so that it links against -lpthread.
This test is not built today, but it will be soon with a future patch.
Reviewed-on: https://go-review.googlesource.com/46451
From-SVN: r249555
The gc toolchain does the same thing, in gentraceback in
runtime/traceback.go.
The test for this is TestPanicTraceback in runtime/crash_test.go. We
don't yet run that test, but we will in a future change.
Reviewed-on: https://go-review.googlesource.com/46397
From-SVN: r249495
libgo: remove old MIPS architecture names
This removes the old names for the 3 main MIPS ABIs: mipso32, mipsn32
and mipsn64. It also removes the mipso64 ABI which has no equivalent
architecture name in go. This ABI has been dead for sometime and I doubt
anyone will miss it.
Change-Id: I087b243784edf6705fdaf9c32e3233da5e387283
From-SVN: r249485
This removes the old names for the 3 main MIPS ABIs: mipso32, mipsn32
and mipsn64. It also removes the mipso64 ABI which has no equivalent
architecture name in go. This ABI has been dead for sometime and I doubt
anyone will miss it.
Reviewed-on: https://go-review.googlesource.com/46154
From-SVN: r249477
Rename getrandom_linux_mipsn32.go to use the new architecture name for
the n32 ABI and enable building it on mips64p32 and mips64p32le.
Reviewed-on: https://go-review.googlesource.com/46151
From-SVN: r249474
On MIPS, the correct structure for PtraceRegs is 'struct pt_regs' which
is declared in linux/ptrace.h. Previously no PtraceRegs structure was
created on MIPS because 'struct user_regs_struct' doesn't exist there.
Fallback to using pt_regs when the PtraceRegs structure is generated in
mksysinfo.sh, then adjust syscall_linux_mipsx.go to read the program
counter from the correct field.
In addition, implement PtraceGetRegs and PtraceSetRegs on all 3 ABI
variants.
syscall_linux_mips64x.go can now be removed since the ptrace code on
all 3 ABIs is identical.
Reviewed-on: https://go-review.googlesource.com/46150
From-SVN: r249473
On MIPS, the correct structure for PtraceRegs is 'struct pt_regs' which
is declared in linux/ptrace.h. Previously no PtraceRegs structure was
created on MIPS because 'struct user_regs_struct' doesn't exist there.
Fallback to using pt_regs when the PtraceRegs structure is generated in
mksysinfo.sh, then adjust syscall_linux_mipsx.go to read the program
counter from the correct field.
In addition, implement PtraceGetRegs and PtraceSetRegs on all 3 ABI
variants.
syscall_linux_mips64x.go can now be removed since the ptrace code on
all 3 ABIs is identical.
Reviewed-on: https://go-review.googlesource.com/46150
From-SVN: r249472
The go tool will pass -I objdir as one of the flags, where objdir is
the temporary build directory. Remove that from _cgo_flags: we don't
need it, and it will be different each time.
Sort the flags to avoid the unpredictable map iteration order.
This matters for gccgo because for a package that uses cgo, the go
tool when building for gccgo will store the _cgo_flags file in the
archive. That means that we want to generate identical _cgo_flags for
every run.
The test for this is the cmd/go testsuite, to follow in a future CL.
Reviewed-on: https://go-review.googlesource.com/45692
From-SVN: r249199
Pass the -fdebug-prefix-map and -gno-record-gcc-switches compiler
options to gccgo to generate consistent results.
Fix the vendoring code to look for /vendor/, not just /vendor, to
avoid being confused by something like vendor/vendor.org.
Tested by the cmd/go tests in a followup CL.
Reviewed-on: https://go-review.googlesource.com/45695
From-SVN: r249198
These tests fail for various reasons, most commonly because gccgo
doesn't really have GOROOT, so things like `go build errors` fail.
Reviewed-on: https://go-review.googlesource.com/45696
From-SVN: r249197
Add the environment variable GCCGOTOOLDIR to permit overriding the default
directory where tools like cgo are found when building with gccgo.
This will be used by the cmd/go tests in a future CL.
Reviewed-on: https://go-review.googlesource.com/45694
From-SVN: r249196
If GO_TESTING_GOTOOLS is set in the environment, permit tests using
gccgo to run the go tool. Like GO_BUILDER_NAME, this should not be set
normally. But it is needed when testing the go tool itself, and will
be set by the gotools Makefile in a future CL.
Reviewed-on: https://go-review.googlesource.com/45693
From-SVN: r249195
If there is no function name, the traceback is generally
uninformative. In earlier versions we did not show such frames.
Restore that behavior. These frames can be seen with GOTRACEBACK=system.
Reviewed-on: https://go-review.googlesource.com/45431
From-SVN: r249156
Otherwise it may be set when the g struct is reused via gfput/gfget.
Test is golang.org/x/net/http2 with GOMAXPROCS=12.
Reviewed-on: https://go-review.googlesource.com/45430
From-SVN: r249143
Also always access the atomicstatus field atomically.
The effect of not checking the _Gscan bit is that if the GC decides to
scan the stack just as the goroutine is leaving the system call, the
goroutine might fail to call exitsyscall. Then then typically causes
a runtime assertion failure later on. If we do call exitsyscall as we
should, it will stall (in casgstatus) until the _Gscan bit is cleared.
No separate test. I've observed causing sporadic failures running the
misc/cgo tests, but we don't currently have a way to run those
routinely for gccgo. I should fix that.
Reviewed-on: https://go-review.googlesource.com/45392
From-SVN: r249138
Ian Lance Taylor