We already use GOHOSTOS to represent the host OS that the toolchain
will be run on, so no need to resort to uname(1) to get that (and
use uname(1) will make cross-compiling for another host impossible).
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5530050
The optable for 0xDB is handled specially.
This was the cause of a really weird bug
when using cov (386!) on the math package.
A real head-scratcher.
R=rsc
CC=golang-dev
https://golang.org/cl/4639066
The brace style in these files are a little inconsistent so I rolled with
it on a per-file basis.
R=dave, r
CC=golang-dev
https://golang.org/cl/4515194
The object files begin with a header that is
$GOARCH
on a line by itself. This CL changes that header to
go object $GOOS $GOARCH release.2011-01-01 4567+
where the final two fields are the most recent release
tag and the current hg version number.
All objects imported into a Go compilation or linked into an
executable must have the same header line, and that header
line must match the compiler and linker versions.
The effect of this will be that if you update and run all.bash
and then try to link in objects compiled with an earlier version
of the compiler (or invoke the wrong version of the compiler),
you will get an error showing the different headers instead
of perhaps silent incompatibility.
Normal usage with all.bash should be unaffected, because
all.bash deletes all the object files in $GOROOT/pkg/$GOOS_$GOARCH
and cleans all intermediate object files before starting.
This change is intended to diagnose stale objects arising when
users maintaining alternate installation directories forget to
rebuild some of their files after updating.
It should help make the adoption of $GOPATH (CL 3780043)
less error-prone.
R=ken2, r
CC=golang-dev
https://golang.org/cl/4023063
That is, move the pc/ln table and the symbol table
into the read-only data segment. This eliminates
the need for a special load command to map the
symbol table into memory, which makes the
information available on systems that couldn't handle
the magic load to 0x99000000, like NaCl and ARM QEMU
and Linux without config_highmem=y. It also
eliminates an #ifdef and some clumsy code to
find the symbol table on Windows.
The bad news is that the binary appears to be bigger
than it used to be. This is not actually the case, though:
the same amount of data is being mapped into memory
as before, and the tables are still read-only, so they're
still shared across multiple instances of the binary as
they were before. The difference is just that the tables
aren't squirreled away in some section that "size" doesn't
know to look at.
This is a checkpoint.
It probably breaks Windows and breaks NaCl more
than it used to be broken, but those will be fixed.
The logic involving -s needs to be revisited too.
Fixes#871.
R=ken2
CC=golang-dev
https://golang.org/cl/2587041
If you look at the sequence of values returned
by waitpid, it simply tells us about the child of
clone before it tells us that the parent called clone.
There's nothing we can do but assume unexpected
tids are newly cloned children.
Tested with 6prof on godoc.
Fixes#251.
R=r
CC=golang-dev
https://golang.org/cl/2167045
the bash scripts and makefiles for building go didn't take into account
the fact $GOROOT / $GOBIN could both be directories containing whitespaces,
and was not possible to build it in such a situation.
this commit adjusts the various makefiles/scripts to make it aware of that
possibility, and now it builds successfully when using a path with whitespaces
as well.
Fixes#115.
R=rsc, dsymonds1
https://golang.org/cl/157067
cgo/libmach remain unimplemented. However, compilers, runtime,
and packages are 100%. I still need to go through and implement
missing syscalls (at least make sure they're all listed), but
for all shipped functionality, this is done. Ship! ;)
R=rsc, VenkateshSrinivas
https://golang.org/cl/152142
better mach binaries.
cgo working on darwin+linux amd64+386.
eliminated context switches - pi is 30x faster.
add libcgo to build.
on snow leopard:
- non-cgo binaries work; all tests pass.
- cgo binaries work on amd64 but not 386.
R=r
DELTA=2031 (1316 added, 626 deleted, 89 changed)
OCL=35264
CL=35304
deciding what the host process support is.
this makes a cross-compiling (e.g., GOOS=nacl) build
still generate valid host debugger binaries.
R=r
DELTA=5 (0 added, 0 deleted, 5 changed)
OCL=34878
CL=34889
