Putting the M initialization in multiple places will not scale.
Various code assumes mstart is the start already. Make it so.
R=golang-dev, devon.odell
CC=golang-dev
https://golang.org/cl/7420048
For now, all the callbacks from C use top-level Go functions,
so they use the equivalent C function pointer, and will continue
to do so. But perhaps some day this will be useful for calling
a Go func value (at least if the type is already known).
More importantly, the Windows callback code needs to be able
to use cgocallback_gofunc to call a Go func value.
Should fix the Windows build.
R=ken2
CC=golang-dev
https://golang.org/cl/7388049
This function uses 48-byte of precious non-split stack for every callback
function, and without this CL, it can easily overflow the non-split stack.
I encountered this when trying to enable misc/cgo/test on windows/amd64.
R=rsc
CC=golang-dev
https://golang.org/cl/5784075
It's the best we can do before Go 1.
For issue 3250; not a fix but at least less mysterious.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5797068
It may have to switch stacks, since we are calling
a DLL instead of a system call.
badcallback says where it is, because it is being called
on a Windows stack already.
R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/5782060
Implement runtime·write, like on the other systems,
and also runtime·badcallback, in assembly to reduce
stack footprint.
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/5785055
When a very low-level system call that should never fail
does fail, we call notok, which crashes the program.
Often, we are then left with only the program counter as
information about the crash, and it is in notok.
Instead, inline calls to notok (it is just one instruction
on most systems) so that the program counter will
tell us which system call is unhappy.
R=golang-dev, gri, minux.ma, bradfitz
CC=golang-dev
https://golang.org/cl/5792048
This is like the ill-fated CL 5493063 except that
I have written a shell script (autogen.sh) instead of
thinking I could possibly write a correct Makefile.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5496075
That was the last build that was close to working.
I will try that change again next week.
Make is being very subtle today.
At the reverted-to CL, the ARM traceback appears
to be broken. I'll look into that next week too.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5492063
Collapse the arch,os-specific directories into the main directory
by renaming xxx/foo.c to foo_xxx.c, and so on.
There are no substantial edits here, except to the Makefile.
The assumption is that the Go tool will #define GOOS_darwin
and GOARCH_amd64 and will make any file named something
like signals_darwin.h available as signals_GOOS.h during the
build. This replaces what used to be done with -I$(GOOS).
There is still work to be done to make runtime build with
standard tools, but this is a big step. After this we will have
to write a script to generate all the generated files so they
can be checked in (instead of generated during the build).
R=r, iant, r, lucio.dere
CC=golang-dev
https://golang.org/cl/5490053
