This makes make.bash pass without any warnings for
$ clang --version
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
The change in src/liblink/asm5.c silences a warning building
on modern macOS, which doesn't actually produce a working
toolchain anyway, but it still seems worth silencing the warning.
These warnings surface now in the reproducible builds reports
(for example https://gorebuild.storage.googleapis.com/gorebuild.html,
click on "Bootstrap go1.4"). I'd rather not look at them anymore.
For golang/go#58884.
Change-Id: I689c862ad360ca23153438f9e143a1cb840730e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/514415
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
OpenBSD 6.4+ requires that stack regions be marked with MAP_STACK.
MAP_STACK is permitted (but is a no-op) on OpenBSD 6.3.
Change-Id: I8118f27e6a0feb97ae570cbc8aad461ec20676fa
Reviewed-on: https://go-review.googlesource.com/c/154477
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The 1.4 tests aren't necessarily supposed to pass.
Disable them by default, to avoid the sort of
unpleasant experience described in #25816.
Change-Id: I763b8e52c8d16f4d9be14ad853df456652e51430
Reviewed-on: https://go-review.googlesource.com/124077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cgo is not supported with 1.4.
In addition to (perhaps instead of) documenting it,
just enforce it in make.*.
Updates Homebrew/homebrew-core#18465
Change-Id: Iefb1860890d9ec525597b6d730e2189110818598
Reviewed-on: https://go-review.googlesource.com/124076
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
This test is now failing due to tz data updates (see issue #19457) - skip the test
since it does not impact the use of Go 1.4 for bootstrapping.
Similar to issue #17545.
Updates #20672
Change-Id: I8017159fa2a59b052c49fda7d50be7a863e0a08d
Reviewed-on: https://go-review.googlesource.com/66073
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change the openbsd runtime to use the current sys_kill and sys_thrkill
system calls.
This is a backport of https://golang.org/cl/34093 to the Go 1.4 branch.
Updates #20672
Change-Id: I4fde5bad2fbfbe99196053d69ba235b49ddb32c8
Reviewed-on: https://go-review.googlesource.com/66072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In future releases of OpenBSD, the sigreturn syscall will no longer
exist. As such, stop using sigreturn on openbsd/386 and just return
from the signal trampoline.
This is a backport of https://golang.org/cl/23024 to the Go 1.4 branch.
Updates #20672
Change-Id: Ia1caf9427c51a6871f51dbff06720f3158e38c68
Reviewed-on: https://go-review.googlesource.com/66071
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The 1.4 branch is now used only for building more recent releases.
Enabling cgo is not required for that, and tends to cause problems as
systems and compilers change.
Updates #21054
Change-Id: I498f493e3ac32bcea55725cf5de3b3172f0fd5db
Reviewed-on: https://go-review.googlesource.com/65450
Reviewed-by: Joe Tsai <joetsai@google.com>
Run-TryBot: Joe Tsai <joetsai@google.com>
This is a backport of https://golang.org/cl/49710 to the Go 1.4 branch.
Original CL description:
GCC says -no-pie, clang says -nopie.
Updates #21042
Change-Id: I67b755ccb0149324098b79e07ee4bbc49429c44c
Reviewed-on: https://go-review.googlesource.com/49711
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a backport of https://golang.org/cl/18359 to the Go 1.4 branch.
This fixes the Go 1.4 build on systems for which the compiler defaults
to using PIE. Such systems are becoming more common.
Original CL description:
Go fails to build on a system which has PIE enabled by default like this:
/usr/bin/ld: -r and -pie may not be used together
collect2: error: ld returned 1 exit status
The only system I know that has this property right now is Ubuntu Xenial
running on s390x, which is hardly the most accessible system, but it's planned
to enable this on amd64 soon too. The fix is to pass -no-pie along with -Wl,-r
to the compiler, but unfortunately that flag is very new as well. So this does
a test compile of a trivial file to see if the flag is supported.
Updates #20276
Change-Id: I80a32fd06e30df1d871a48b5db225ba5bb5d104b
Reviewed-on: https://go-review.googlesource.com/42910
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a cherry-pick of https://go-review.googlesource.com/21190
to release-branch-go1.4. Diff prepared by Ian Lance Taylor.
linux/386 depends on modify_ldt system call, but recent Linux kernels
can disable this system call. Any Go programs built as linux/386
crash with the message 'Trace/breakpoint trap'.
The kernel config CONFIG_MODIFY_LDT_SYSCALL, which control
enable/disable modify_ldt, is disabled on Amazon Linux 2016.03.
This fixes this problem by using set_thread_area instead of modify_ldt
on linux/386.
Fixes#14795.
Change-Id: I22a67d6119e5d24afaa01e2c2b8174991a8a9bf4
Reviewed-on: https://go-review.googlesource.com/31753
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The version of cmd/api on the release-go1.4 branch
thinks the go.tools repo lives at code.google.com.
There's no point in fixing it; disable it.
Change-Id: Ieb189b1286b86b1d49a264548ee262301c95b014
Reviewed-on: https://go-review.googlesource.com/31752
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a cherry-pick of https://go-review.googlesource.com/25400
to the release-branch-go1.4
macOS Sierra beta4 changed the kernel interface for getting time.
DX now optionally points to an address for additional info.
Set it to zero to avoid corrupting memory.
Fixes#16570
Change-Id: I714325a7749a145d23cf03251db38196ac9c481a
Reviewed-on: https://go-review.googlesource.com/31750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a cherry-pick of https://go-review.googlesource.com/24812
to the release-branch-go1.4
In the beta version of the macOS Sierra (10.12) release, the
gettimeofday system call changed on x86. Previously it always returned
the time in the AX/DX registers. Now, if AX is returned as 0, it means
that the system call has stored the values into the memory pointed to by
the first argument, just as the libc gettimeofday function does. The
libc function handles both cases, and we need to do so as well.
Fixes#16272.
Change-Id: I490ed0a82e251fce73becc4722cbe276feebc7b7
Reviewed-on: https://go-review.googlesource.com/31729
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Backport of golang.org/cl/16529 to release-branch.go1.4.
I wanted to build go 1.4 packages for Xenial so I did this. It's not enough for
1.4.4 but it may as well be included if we ever find a reason to release that,
so I thought I'd send it in.
Change-Id: I907627586e6c7a0580ae447a349c0e3534d64e3d
Reviewed-on: https://go-review.googlesource.com/21598
Reviewed-by: Russ Cox <rsc@golang.org>
This CL contains the verbatim tests from these two changes, but with
alternate minimal fixes against the 1.4 tree:
https://go-review.googlesource.com/#/c/12865/https://go-review.googlesource.com/#/c/13148/
Change-Id: If98c2198e24e30e14a3b7b5e954b504d1f18db89
Reviewed-on: https://go-review.googlesource.com/14802
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Run-TryBot: Chris Broadfoot <cbro@golang.org>
This was originally done in https://codereview.appspot.com/5690059
(Feb 2012) to deal with bad response headers coming back from webcams,
but it presents a potential security problem with HTTP request
smuggling for request headers containing "Content Length" instead of
"Content-Length".
Part of overall HTTP hardening for request smuggling. See RFC 7230.
Thanks to Régis Leroy for the report.
Change-Id: I92b17fb637c9171c5774ea1437979ae2c17ca88a
Reviewed-on: https://go-review.googlesource.com/11772
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/14249
Reviewed-by: Andrew Gerrand <adg@golang.org>
The 32-bit heap may have holes in it. Pointers to (non-heap) objects
in those holes shouldn't cause the GC to throw.
This change is somewhat of a band-aid fix for 1.4.2. We should do
a more thorough fix for tip (keep track of the holes in the heap
with special MSpans, say).
Update #9872
Change-Id: Ife9ba27b77ae6ac5a6792d249c68893b3df62134
Reviewed-on: https://go-review.googlesource.com/4920
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The compiler has a phase ordering problem. Escape analysis runs
before wrapper generation. When a generated wrapper calls a method
defined in a different package, if that call is inlined, there will be
no escape information for the variables defined in the inlined call.
Those variables will be placed on the stack, which fails if they
actually do escape.
There are probably various complex ways to fix this. This is a simple
way to avoid it: when a generated wrapper calls a method defined in a
different package, treat all local variables as escaping.
Fixes#9537.
Change-Id: I530f39346de16ad173371c6c3f69cc189351a4e9
Reviewed-on: https://go-review.googlesource.com/3092
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit ec0ebc2281f79294c299ece35c5a690a6415e0e0)
Reviewed-on: https://go-review.googlesource.com/5003
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes#9871 for Go 1.4.
Change-Id: I550a5bdb29e9a872652e0dd468a434227d7d9502
Reviewed-on: https://go-review.googlesource.com/4937
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>
We were failing ^uint16(0xffff) == 0, as we computed 0xffff0000 instead.
I could only trigger a failure for the above case, the other two tests
^uint16(0xfffe) == 1 and -uint16(0xffff) == 1 didn't seem to fail
previously. Somehow they get MOVHUs inserted for other reasons (used
by CMP instead of TST?). I fixed OMINUS anyway, better safe than
sorry.
Fixes#9604
Change-Id: I4c2d5bdc667742873ac029fdbe3db0cf12893c27
Reviewed-on: https://go-review.googlesource.com/2940
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit daa64ddfe64dda368e80cf224dc485fa63386f81)
Reviewed-on: https://go-review.googlesource.com/5002
The comment says to use (y-1), but then we did add(y.abs, natOne). We meant sub.
Fixes#9609
Change-Id: I4fe4783326ca082c05588310a0af7895a48fc779
Reviewed-on: https://go-review.googlesource.com/2961
Reviewed-by: Robert Griesemer <gri@golang.org>
(cherry picked from commit c6ddca2aec4218e1af7f51fad3b761afb33b4c20)
Reviewed-on: https://go-review.googlesource.com/5001
Remove carriage returns from //go:generate lines.
Carriage returns are the predecessor of BOMs and still
live on Windows.
Fixes#9264
Change-Id: I637748c74335c696b3630f52f2100061153fcdb4
Reviewed-on: https://go-review.googlesource.com/1564
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
(cherry picked from commit fde3ab843faaf4ba7a741bfdc192dbb5f2ddf209)
Reviewed-on: https://go-review.googlesource.com/4999
Reviewed-by: David Symonds <dsymonds@golang.org>
I am an idiot but the failure to implement this means we can decide
exactly what its design should be for 1.5
Change-Id: Ie2b025fcd899d306ddeddd09d1d0e8f9a99ab7a8
Reviewed-on: https://go-review.googlesource.com/4291
Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 1e5d8bb5444368a7b6f2f169bbbb43452a0479d9)
Reviewed-on: https://go-review.googlesource.com/4998
Reviewed-by: David Symonds <dsymonds@golang.org>
OpenBSD 5.5 changed its kernel ABI and OpenBSD 5.6 enabled it.
This CL works on both 5.5 and 5.6.
Fixes#9102.
Change-Id: I4a295be9ab8acbc99e550d8cb7e8f8dacf3a03c5
Reviewed-on: https://go-review.googlesource.com/1932
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 13e16b39fc269fcba3383bd6c133da3e0e0345e9)
Reviewed-on: https://go-review.googlesource.com/2826
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It shouldn't semacquire() inside an acquirem(), the runtime
thinks that means deadlock. It actually isn't a deadlock, but it
looks like it because acquirem() does m.locks++.
Candidate for inclusion in 1.4.1. runtime.Stack with all=true
is pretty unuseable in GOMAXPROCS>1 environment.
fixes#9321
Change-Id: Iac6b664217d24763b9878c20e49229a1ecffc805
Reviewed-on: https://go-review.googlesource.com/1600
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 50bc3d5bbc6710663c082aa72c8ba4f9ee515ab3)
Reviewed-on: https://go-review.googlesource.com/2807
Reviewed-by: Andrew Gerrand <adg@golang.org>
CL 2789 backported a change that required a barrage of followup CLs.
This CL backports all the followup CLs together.
There are manual edits to os_plan9.go and syscall_windows.go to take
the place of edits to defs_windows_{amd64,386}.go and os2_plan9.go
in the original. Those files do not exist in the release branch, but the
definition being added must go somewhere.
Original change descriptions below.
---
runtime/cgo: initialize our pthread_create wrapper earlier on openbsd
This is a genuine bug exposed by our test for issue 9456: our wrapper
for pthread_create is not initialized until we initialize cgo itself,
but it is possible that a static constructor could call pthread_create,
and in that case, it will be calling a nil function pointer.
Fix that by also initializing the sys_pthread_create function pointer
inside our pthread_create wrapper function, and use a pthread_once to
make sure it is only initialized once.
Fix build for openbsd.
Change-Id: Ica4da2c21fcaec186fdd3379128ef46f0e767ed7
Reviewed-on: https://go-review.googlesource.com/2232
Reviewed-by: David Crawshaw <crawshaw@golang.org>
(cherry picked from commit 77cd6197d7561ab7ccbf5d892efb6f97d929546a)
---
runtime: provide a dummy value of _SIGPROF on plan9 and windows
Fixes build on plan9 and windows.
Change-Id: Ic9b02c641ab84e4f6d8149de71b9eb495e3343b2
Reviewed-on: https://go-review.googlesource.com/2233
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
(cherry picked from commit 1f282385579fc404f1246fd7ffa8b4e517401d19)
---
runtime/cgo: remove unused variable
I missed this one in golang.org/cl/2232 and only tested the patch
on openbsd/amd64.
Change-Id: I4ff437ae0bfc61c989896c01904b6d33f9bdf0ec
Reviewed-on: https://go-review.googlesource.com/2234
Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 0b2a74e89cf940e1c4cd91785ff3d744684edc49)
---
runtime: skip TestCgoExternalThreadSIGPROF on OS X 10.6
The test program requires static constructor, which in turn needs
external linking to work, but external linking never works on 10.6.
This should fix the darwin-{386,amd64} builders.
Change-Id: I714fdd3e35f9a7e5f5659cf26367feec9412444f
Reviewed-on: https://go-review.googlesource.com/2235
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2cbe27a27202dca5a643b75c79e25d4cccc3ae67)
---
runtime: fix TestCgoExternalThreadSIGPROF again
Shell out to `uname -r` this time, so that the test will compile
even if the platform doesn't have syscall.Sysctl.
Change-Id: I3a19ab5d820bdb94586a97f4507b3837d7040525
Reviewed-on: https://go-review.googlesource.com/2271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 865e5e98b685eb3a7888f5263021049c0694d16f)
---
runtime: remove unnecessary GOOS switch
Change-Id: I8f518e273c02110042b08f7c50c3d38a648c8b6e
Reviewed-on: https://go-review.googlesource.com/2281
Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 1ebfb082a7a5cc31efd572fd88549048a82a5c1c)
---
Change-Id: Ifee9667ca90eda2b074817c319b1b7c66d4f741d
Reviewed-on: https://go-review.googlesource.com/2805
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Pointers to zero-sized values may end up pointing to the next
object in memory, and possibly off the end of a span. This
can cause memory leaks and/or confuse the garbage collector.
By putting the overflow pointer at the end of the bucket, we
make sure that pointers to any zero-sized keys or values don't
accidentally point to the next object in memory.
fixes#9384
Change-Id: I5d434df176984cb0210b4d0195dd106d6eb28f73
Reviewed-on: https://go-review.googlesource.com/1869
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit fbc56cf05015899aba236d5a68096a770de3ad0a)
Reviewed-on: https://go-review.googlesource.com/2801
Reviewed-by: Andrew Gerrand <adg@golang.org>
malloc checks kindNoPointers and if it is not set and the object
is one pointer in size, it assumes it contains a pointer. So we
must set kindNoPointers correctly; it isn't just a hint.
Fixes#9425
Change-Id: Ia43da23cc3298d6e3d6dbdf66d32e9678f0aedcf
Reviewed-on: https://go-review.googlesource.com/2055
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit d11f41118116e0b5c2fb3b3296323d888dff2d6e)
Reviewed-on: https://go-review.googlesource.com/2800
Reviewed-by: Andrew Gerrand <adg@golang.org>
