Before this, the heap location used on a 64-bit system was not
available to user-space on arm64, so the "32-bit" strategy ended up
being used. So use somewhere that is available, and for bonus points
is far away from where the kernel allocates address space by default.
From-SVN: r207977
The spans array is allocated in runtime_mallocinit. On a
32-bit system the number of entries in the spans array is
MaxArena32 / PageSize, which (2U << 30) / (1 << 12) == (1 << 19).
So we are allocating an array that can hold 19 bits for an
index that can hold 20 bits. According to the comment in the
function, this is intentional: we only allocate enough spans
(and bitmaps) for a 2G arena, because allocating more would
probably be wasteful.
But since the span index is simply the upper 20 bits of the
memory address, this scheme only works if memory addresses are
limited to the low 2G of memory. That would be OK if we were
careful to enforce it, but we're not. What we are careful to
enforce, in functions like runtime_MHeap_SysAlloc, is that we
always return addresses between the heap's arena_start and
arena_start + MaxArena32.
We generally get away with it because we start allocating just
after the program end, so we only run into trouble with
programs that allocate a lot of memory, enough to get past
address 0x80000000.
This changes the code that computes a span index to subtract
arena_start on 32-bit systems just as we currently do on
64-bit systems.
From-SVN: r206501
I am reliably informed that the architecture name and letter for the
plan9/inferno compilers for 64-bit ARM systems will be "arm64" and "7"
respectively, so let's get that bit in nice and early.
From Michael Hudson-Doyle.
https://codereview.appspot.com/34830045/
From-SVN: r206374
On Solaris, if you do a in-progress connect, and then the
server accepts and closes the socket, the client's later
attempt to complete the connect will fail with EINVAL. Handle
this case by assuming that the connect succeeded. This code
is weird enough that it is implemented as Solaris-only so that
it doesn't hide a real error on a different OS.
See http://golang.org/issue/6828.
From-SVN: r206232
PR go/59506
net: use DialTimeout in TestSelfConnect
Backported from master repository.
This avoids problems with systems that take a long time to
find out nothing is listening, while still testing for the
self-connect misfeature since a self-connect should be fast.
With this we may be able to remove the test for non-Linux
systems.
Tested (on GNU/Linux) by editing selfConnect in
tcpsock_posix.go to always return false and verifying that
TestSelfConnect then fails with and without this change.
Idea from Uros Bizjak.
From-SVN: r206224
When a 386 function returns a struct, it needs to return using
an rtd instruction that pops the hidden struct parameter off
the stack. That wasn't happening.
From-SVN: r205551
In particular this means that the names Getsockname returns are not
truncated to 26 characters.
Fixes issue 6829
https://codereview.appspot.com/31840043/
From-SVN: r205368
Fixes issue 6761
This simple change seems to work fine, slightly to my surprise.
This includes the tests I submitted to the main Go repository at
https://codereview.appspot.com/26570046
From-SVN: r205001
If cmd/go is rebuilt using -compiler gccgo the version of go/build that is linked into that cmd/go will not function properly as the list of file suffixes know as operating systems or architectures is incorrect.
From-SVN: r204794
