Backport https://golang.org/cl/163237 from the master library:
Ensure that cmd/go consistently calls base.Exit rather than os.Exit,
so that we don't incorrectly leave the work directory around on exit.
Test this by modifying the testsuite to run all the tests with TMPDIR
set to a temporary directory, and then check that no files are left
behind in that temporary directory. Adjust a couple of tests to make
this approach work.
Updates https://gcc.gnu.org/PR89406
Reviewed-on: https://go-review.googlesource.com/c/163198
From-SVN: r269086
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
Currently, the compiler lowers runtime.getcallersp to
__builtin_frame_address(1). In the C side of the runtime,
getcallersp is defined as __builtin_frame_address(0). They don't
match. Further, neither of them actually returns the caller's SP.
On AMD64, __builtin_frame_address(0) just returns the frame
pointer. __builtin_frame_address(1) returns the memory content
where the frame pointer points to, which is typically the
caller's frame pointer but can also be garbage if the frame
pointer is not enabled.
This CL changes it to use __builtin_dwarf_cfa(), which returns
the caller's SP at the call site. This matches the SP we get
from unwinding the stack.
Currently getcallersp is not used for anything real. It will be
used for precise stack scan (a new version of CL 159098).
Reviewed-on: https://go-review.googlesource.com/c/162905
* go-gcc.cc (Gcc_backend::Gcc_backend): Define __builtin_dwarf_cfa
instead of __builtin_frame_address.
From-SVN: r268952
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
Also stop converting st_dev on Hurd; it shouldn't appear, but if it
somehow does we don't want to convert it.
Reviewed-on: https://go-review.googlesource.com/c/161961
From-SVN: r268785
PR go/89199
sync/atomic: use strong form of atomic_compare_exchange_n
In the recent change to use atomic_compare_exchange_n I thought we
could use the weak form, which can spuriously fail. But that is not
how it is implemented in the gc library, and it is not what the rest
of the library expects.
Thanks to Lynn Boger for identifying the problem.
Fixes https://gcc.gnu.org/PR89199
Reviewed-on: https://go-review.googlesource.com/c/161359
From-SVN: r268591
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
For the gofrontend copy, change calls to types.SizesFor to pass
"gccgo" rather than "gc". Leave the asmdecl pass unchanged since that
pass is gc-specific anyhow.
This has been fixed in a better way in the external repo by
https://golang.org/cl/158317 and friends, but that is not in 1.12, so
use this approach for now.
Reviewed-on: https://go-review.googlesource.com/c/158842
From-SVN: r268153
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
Many C syscall functions take pointer arguments. The pointers
don't escape in the C functions. Mark the C functions noescape so
calling them doesn't need allocation.
Reviewed-on: https://go-review.googlesource.com/c/158158
From-SVN: r267989
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 following CL 156038. doscanstackswitch uses the same
mechanism of switching goroutines as getTraceback, and so has
the same problem as described in issue golang/go#29448. This CL
applies the same fix.
Reviewed-on: https://go-review.googlesource.com/c/156697
From-SVN: r267661
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
Traceback routines, e.g. callers and funcentry, may call
__go_get_backtrace_state. If a profiling signal arrives while we
are in the critical section of __go_get_backtrace_state, it tries
to do a traceback, which also calls __go_get_backtrace_state,
which tries to enter the same critical section and will deadlock.
Prevent this deadlock by setting up runtime_in_callers before
calling __go_get_backtrace_state.
Found while investigating golang/go#29448. Will add a test in the
next CL.
Updates golang/go#29448.
Reviewed-on: https://go-review.googlesource.com/c/156037
From-SVN: r267590
Precise stack scan needs to unwind the stack. When it is
unwinding the stack, if a profiling signal arrives, which also
does a traceback, it may deadlock in dl_iterate_phdr. Prevent
this deadlock by setting up runtime_in_callers before traceback.
Reviewed-on: https://go-review.googlesource.com/c/155766
From-SVN: r267457
On ARM32 EABI, unlike other platforms, the personality function is
called during _Unwind_Backtrace (libgcc/unwind-arm-common.inc:581).
In this case, simply unwind the frame without returning any
handlers. Otherwise traceback will loop if there is a frame with
a defer on stack.
Reviewed-on: https://go-review.googlesource.com/c/155759
From-SVN: r267434
On ARM32 EABI, when the "compact" unwinding model is used, it
does not have standard LSDA and _Unwind_GetLanguageSpecificData
will not return data that is parseable by us. Check this
conditon before calling _Unwind_GetLanguageSpecificData.
Fix ARM32 build.
Reviewed-on: https://go-review.googlesource.com/c/155758
From-SVN: r267428
The type table encoding can be DW_EH_PE_absptr, but this case
was missing, which was causing abort on ARM32 EABI. Add the
missing case.
Reviewed-on: https://go-review.googlesource.com/c/153857
From-SVN: r267070
This increases the time to wait for signals to be delivered in the
TestAtomicStop testcase. When running gccgo tests on ppc64 or ppc64le,
there are intermittent failures in this test because the wait time is
too small.
Updates golang/go#29046
Reviewed-on: https://go-review.googlesource.com/c/153879
From-SVN: r267068
ARM32 EABI unwinder does not define _URC_NORMAL_STOP. Instead,
it has _URC_FAILURE. Use _URC_FAILURE there.
Should fix ARM32 build.
Reviewed-on: https://go-review.googlesource.com/c/153417
From-SVN: r267033
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
In buildmodeinit, the c-archive buildmode is flagged as invalid
on linux/ppc64 for gccgo when it should be valid. This happens
because the check against the gccgo flag is done after the checks
for valid GOOS/GOARCH pairs instead of before as is done for all
other buildmode cases in this switch. This corrects the problem and
allows several of the gccgo gotools testcases to pass on linux/ppc64.
Updates #29046
Reviewed-on: https://go-review.googlesource.com/c/152137
From-SVN: r266764
For inlined function bodies we're going to need to refer to variables,
so change the existing export data to add a '$' to names that look
like identifiers: true, false, nil, convert.
While we're here drop an unnecessary space character after operators.
Reviewed-on: https://go-review.googlesource.com/c/150067
From-SVN: r266529
Create a framework for putting function bodies in export data. At
present only empty functions will be put there, and they will be
ignored on import. Later patches will get this to the point of
supporting inlining of (some) functions defined in other packages.
Reviewed-on: https://go-review.googlesource.com/c/150061
From-SVN: r266490
PR go/88060
syscall: always define _AT_FDCWD and IPv6MTUInfo
They aren't defined by old versions of glibc, but are required by the
code in syscall_linux.go.
Reviewed-on: https://go-review.googlesource.com/c/150697
From-SVN: r266333
The code to implement new-style gccgo name mangling had a recipe that
didn't quite match the one in the compiler (incorrect handling for
'.'). This showed up as a failure in the gotools cgo test if the
directory containing the test run included a "." character.
Reviewed-on: https://go-review.googlesource.com/c/147917
From-SVN: r265981
PR bootstrap/82856
libgo: update to autoconf 2.69 and automake 1.15.1
Initial patch from Joseph Myers.
Reviewed-on: https://go-review.googlesource.com/c/146417
From-SVN: r265701
Fix asm name directive for the C version of log/syslog.syslog_c,
which didn't get included in the recent name mangling change.
Reviewed-on: https://go-review.googlesource.com/c/145017
From-SVN: r265533
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
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
Move the list of libgo, gotool, and check-target packages into
separate files, then read the file contents as part of the build
process on the fly. This is intended to enable other build tooling to
share the canonical list of target packages (avoid duplication).
Reviewed-on: https://go-review.googlesource.com/89515
libgo: revise rules for runtime.inc generation
Refactor code for generating runtime.inc: extract out the relevant
commands and place them in a separate shell script ("mkruntimeinc.sh").
Update rules to avoid generating macros whose names begin with "$",
such as "#define $sinkconst0 0".
Reviewed-on: https://go-review.googlesource.com/85955
From-SVN: r259863
The C portion of the Go runtime includes the header "unwind-pe.h" from
libgcc, which contains some constants and a few small routines for
decoding pointer values within unwind info. This patch gets rid of
that include and instead adds a re-implementation of that
functionality in the single file that uses it. The intent is to allow
the C runtime portion of libgo to be built without a companion GCC
installation.
Reviewed-on: https://go-review.googlesource.com/90235
From-SVN: r259861
Bring in https://golang.org/cl/98616 from gc tip.
Original CL description:
This change modifies Go to disable loading of users' shell history for
TestTerminalSignal tests. TestTerminalSignal, as part of its workload,
will execute a new interactive bash shell. Bash will attempt to load the
user's history from the file pointed to by the HISTFILE environment
variable. For users with large histories that may take up to several
seconds, pushing the whole test past the 5 second timeout and causing
it to fail.
Reviewed-on: https://go-review.googlesource.com/107624
From-SVN: r259452
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
Also add noinst_DATA to CHECK_DEPS; it's not needed in practice since
`make` will build noinst_DATA, but it's logically required and will
make a difference if any of the noinst_DATA sources change between
`make` and `make check`.
Tony Reix figured out why omitting packages from noinst_DATA didn't
seem to matter: because if gccgo can't find foo.gox, it will fall back
to reading the export data in foo.o, and foo.o will exist because
these packages go into libgo.a.
Reviewed-on: https://go-review.googlesource.com/101077
From-SVN: r258606
Makefile: add internal/trace to noinst_DATA
The internal/trace package is only imported by tests (specifically the
tests in runtime/trace) so it must be in noinst_DATA to ensure that it
is built before running the tests.
This was mostly working because internal/trace has tests itself, and
is listed in check-packages.txt before runtime/trace, so typical
invocations of make would build internal/trace for checking purposes
before checking runtime/trace. But we need this change to make that
reliable.
Reviewed-on: https://go-review.googlesource.com/99836
From-SVN: r258392
This implements the same choices made in the gc runtime, except that
for 32-bit x86 we only use the fence instruction if the processor
supports SSE2.
The code here is hacked up for speed; the gc runtime uses straight
assembler.
Reviewed-on: https://go-review.googlesource.com/97715
From-SVN: r258336
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
If we trace back through code that has no debug info, as when calling
through C code compiled with -g0, we won't have a function name.
Try to fetch the function name using the symbol table.
Adding the test case revealed that gotest failed to use the gccgo tag
when matching files, so add that.
Reviewed-on: https://go-review.googlesource.com/92756
From-SVN: r257495
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
I forgot to update the name of the map[string]bool type descriptor
used in go-fieldtrack.c. This didn't cause any errors because it's a
weak symbol, and the current testsuite has no field tracking tests.
Reviewed-on: https://go-review.googlesource.com/91096
From-SVN: r257249
On AIX nm displays symbols with a leading dot; don't discard such
symbols.
While we're here stop doing fgrep -v '$', symbol names no longer
contain '$' anyhow.
Reviewed-on: https://go-review.googlesource.com/91095
From-SVN: r257247
