Introduce a new "types" command to the export data to record the
number of types and the size of their export data. It is immediately
followed by new "type" commands that can be indexed. Parse all the
exported types immediately so that we register them, but parse other
type data only as needed.
Reviewed-on: https://go-review.googlesource.com/c/143022
From-SVN: r265409
Previously when export data referred to a type that was not defined in
a directly imported package, we would write the package name as
additional information in the type's export data. That approach
required all type information to be read in order. This patch changes
the compiler to find all references to indirectly imported packages,
and write them out as an indirectimport line in the import data. This
will permit us to read exported type data out of order.
The type traversal used to find indirect imports is a little more
complicated than necessary in preparation for later patches in this
series.
Reviewed-on: https://go-review.googlesource.com/c/143020
From-SVN: r265296
The export data, which is approximately readable and looks something
like Go, was first implemented back when Go still used semicolons.
Drop the semicolons, to make it look slightly more Go like and make it
slightly smaller.
This updates the compiler and the gccgoimporter package.
This introduces a new version of the export data. There are going to
be more changes to the export data, so this version is still subject
to change.
Reviewed-on: https://go-review.googlesource.com/c/143018
From-SVN: r265284
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
Use inline assembly in the implementation of internal_cpu.xgetbv as
opposed to a call to the intrinsic _xgetbv(), since non-gcc compilers
(e.g. clang) may or may not have support for it.
Reviewed-on: https://go-review.googlesource.com/c/140137
From-SVN: r264882
This reportedly happens on CentOS 5.11. The real code will work fine;
this test is assuming that the unexported slice function will handle
the splice, but if pipe2 does not work then it doesn't. The relevant
code in internal/poll/splice_linux.go says "Falling back to pipe is
possible, but prior to 2.6.29 splice returns -EAGAIN instead of 0 when
the connection is closed."
Reviewed-on: https://go-review.googlesource.com/138838
From-SVN: r264793
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
Rewrite the arm64 AES hashing code from gc assembler to C code using
intrinsics. The resulting code generates the same hash code for the
same input as the gc code--that doesn't matter as such, but testing it
ensures that the C code does something useful.
Reviewed-on: https://go-review.googlesource.com/138535
From-SVN: r264771
On Alpha GNU/Linux there is no geteuid system call, there is only
getresuid. The raw geteuid system call is only used for testing, so
just skip the test if it's not available.
Reviewed-on: https://go-review.googlesource.com/137655
From-SVN: r264647
In internal/bytealg correct a +build tag to never build indexbyte_generic.go
for the gofrontend, where we always use indexbyte_native.go.
For internal/cpu let the Makefile define CacheLineSize using goarch.sh,
rather than trying to enumerate all the possibilities in cpu_ARCH.go files.
In internal/poll call the C fcntl function rather than using SYS_FCNTL.
Change mksysinfo.sh to ensure that F_GETPIPE_SZ is always defined,
and check that in internal/poll.
Reviewed-on: https://go-review.googlesource.com/137256
From-SVN: r264572
This permits TestScript to work when gccgo is not installed.
Previous testing was using a previously installed gccgo, not the newly
built one.
This revealed that the testing of whether an internal package is
permitted was incorrect for standard library packages, since the
uninstalled gccgo can see internal packages in the uninstalled libgo.
Fix the internal package tests.
This permitted removing a couple of gccgo-specific changes in the
testsuite.
Reviewed-on: https://go-review.googlesource.com/137255
From-SVN: r264570
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
Fix up the testing package to insure that execution traces
work properly (e.g. "-test.trace=<XXX>" command line option). The
call to stop tracing and emit the output file was stubbed out.
Reviewed-on: https://go-review.googlesource.com/128275
From-SVN: r263363
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
PR go/86331
os: check return value as well as error from waitid
https://gcc.gnu.org/PR86331 indicates that if a signal handler runs it
is possible for syscall.Syscall6 to return a non-zero errno value even
if no error occurs. That is a problem in general, but this fix will
let us work around the general problem for the specific case of
calling waitid.
Reviewed-on: https://go-review.googlesource.com/121595
From-SVN: r262313
USING_SPLIT_STACK is configured as defined/undefined, not 0/1.
Most of the places test USING_SPLIT_STACK with #ifdef, with a
few exceptions. This CL fixes the exceptions.
Reviewed-on: https://go-review.googlesource.com/120596
From-SVN: r261980
Adjust the hash and string fields computed by StructOf to match the
values that the compiler computes for a struct type with the same
field names and types. This makes the reflect code match the
compiler's Type::hash_for_method and Type::reflection methods.
Fixesgolang/go#25284
Reviewed-on: https://go-review.googlesource.com/116515
From-SVN: r261235
Background: since gccgo does not currently merge identical types at link time,
the reflect function canonicalize() exists to choose a canonical specimen
for each set of identical types.
In this way, user code has the guarantee that identical types
will always compare as ==
Change: arrange reflect functions MapOf(), SliceOf(), StructOf() etc.
to call canonicalize() on the types they create, before storing the types
in internal lookup caches and returning them.
This fixes known cases where canonicalize() is needed but was missing.
Supersedes https://golang.org/cl/112575 and mostly fixes issue 25284.
Updates golang/go#25284
Reviewed-on: https://go-review.googlesource.com/115577
From-SVN: r261216
Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
cmd/go: don't pass -compiler flag to vet
Without this running go vet -compiler=gccgo causes vet to fail.
The vet tool does need to know the compiler, but it is passed in
vetConfig.Compiler.
cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
When using gccgo/GoLLVM, there is no package file for a standard
library package. Since it is impossible for the go tool to rebuild the
package, and since the package file exists only in the form of a .gox
file, this seems like the best choice. Unfortunately it was confusing
vet, which wanted to see a real file. This caused vet to report errors
about missing package files for standard library packages. The
gccgoimporter knows how to correctly handle this case. Fix this by
1) telling vet which packages are standard;
2) letting vet skip those packages;
3) letting the gccgoimporter handle this case.
As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
so don't try to depend on it (as it happens, this fixesgolang/go#25324).
The result is that the cmd/go vet tests pass when using -compiler=gccgo.
Reviewed-on: https://go-review.googlesource.com/114516
From-SVN: r260913
Several recent changes to the gc version of cmd/go improve the
gofrontend support. These changes are partially copies of existing
gofrontend differences, and partially new code. This CL makes the
gofrontend match the upstream code.
The changes included here come from:
https://golang.org/cl/111575https://golang.org/cl/111595https://golang.org/cl/111635https://golang.org/cl/111636
For the record, the following recent gc changes are based on code
already present in the gofrontend repo:
https://golang.org/cl/110915https://golang.org/cl/111615
For the record, a gc change, partially based on earlier gofrontend
work, also with new gc code, was already copied to gofrontend repo in
CL 111099:
https://golang.org/cl/111097
This moves the generated list of standard library packages from
cmd/go/internal/load to go/build.
Reviewed-on: https://go-review.googlesource.com/112475
gotools/:
* Makefile.am (check-go-tool): Don't copy zstdpkglist.go.
* Makefile.in: Rebuild.
From-SVN: r260097
In https://golang.org/cl/111097 the gc version of cmd/go was updated
to include some gofrontend-specific changes. The gofrontend code
already has different versions of those changes; this CL makes the
gofrontend match the upstream code.
Reviewed-on: https://go-review.googlesource.com/111099
From-SVN: r259918
These tests used to be disabled in the gofrontend since the go tool
didn't support build IDs for the gofrontend. It does now, so enable
the tests again.
Reviewed-on: https://go-review.googlesource.com/111098
From-SVN: r259875
This patch adds explicit references to various types and constants
defined by the header files included by sysinfo.c (used to drive the
generation of gen-sysinfo.go as part of the libgo build via the GCC
"-fdump-go-spec" option).
The intent is to enable clients to gather the same info generated by
"-fdump-go-spec" by instead reading the generated DWARF from a
sysinfo.o object file compiled with "-g". Some compilers (notably
clang) try to omit DWARF records for a given type unless there is an
explicit use of it in the translation unit; the additional references
are to insure that everything we want to see in the DWARF shows up.
Reviewed-on: https://go-review.googlesource.com/99063
From-SVN: r259868
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
