The new //export comment marks a Go function as callable from
C.  The syntax is "//export NAME" where NAME is the name of
the function as seen from C.  If such a comment is seen, cgo
will generate two new files: _cgo_export.h and _cgo_export.c.
The _cgo_export.h file provides declarations which C code may
use to call Go functions.  The _cgo_export.c file contains
wrappers, and is to be compiled with gcc.

The changes to Make.pkg support using this from a Go Makefile,
though it could probably be more convenient.

R=rsc
CC=golang-dev
https://golang.org/cl/853042

These functions are used to call from a C function back to a
Go function.  This only includes 386 support.

R=rsc
CC=golang-dev
https://golang.org/cl/834045

R=rsc
CC=golang-dev
https://golang.org/cl/857045

R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/854045

R=rsc
CC=golang-dev
https://golang.org/cl/902042

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/872043

R=adg
CC=golang-dev
https://golang.org/cl/867046

tested on linux/amd64, linux/386, linux/arm, darwin/amd64, darwin/386.
freebsd untested; will finish in a separate CL.

for now all the panics are errorStrings.
richer structures can be added as necessary
once the mechanism is shaked out.

R=r
CC=golang-dev
https://golang.org/cl/906041

when garbage collector sees recovering goroutine

Fixes #711.

R=r
CC=golang-dev
https://golang.org/cl/869045

Could not take a signal on threads other than the main thread.
If you look at the spinning binary with dtrace, you can see a
fault happening over and over:

    $ dtrace -n '
    fbt::user_trap:entry /execname=="boot32" && self->count < 10/
    {
        self->count++;
        printf("%s %x %x %x %x", probefunc, arg1, arg2, arg3, arg4);
        stack();
        tracemem(arg4, 256);
    }'

    dtrace: description 'fbt::user_trap:entry ' matched 1 probe
    CPU     ID                    FUNCTION:NAME
      1  17015                  user_trap:entry user_trap 0 10 79af0a0 79af0a0
                  mach_kernel`lo_alltraps+0x12a

             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
         0: 0e 00 00 00 37 00 00 00 00 00 00 00 1f 00 00 00  ....7...........
        10: 1f 00 00 00 a8 33 00 00 00 00 00 01 00 00 00 00  .....3..........
        20: 98 ba dc fe 07 09 00 00 00 00 00 00 98 ba dc fe  ................
        30: 06 00 00 00 0d 00 00 00 34 00 00 00 9e 1c 00 00  ........4.......
        40: 17 00 00 00 00 02 00 00 ac 30 00 00 1f 00 00 00  .........0......
        50: 00 00 00 00 00 00 00 00 0d 00 00 00 e0 e6 29 00  ..............).
        60: 34 00 00 00 00 00 00 00 9e 1c 00 00 00 00 00 00  4...............
        70: 17 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00  ................
        80: ac 30 00 00 00 00 00 00 1f 00 00 00 00 00 00 00  .0..............
        90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        a0: 48 00 00 00 10 00 00 00 85 00 00 00 a0 f2 29 00  H.............).
        b0: 69 01 00 02 00 00 00 00 e6 93 04 82 ff 7f 00 00  i...............
        c0: 2f 00 00 00 00 00 00 00 06 02 00 00 00 00 00 00  /...............
        d0: 78 ee 42 01 01 00 00 00 1f 00 00 00 00 00 00 00  x.B.............
        e0: 00 ed 9a 07 00 00 00 00 00 00 00 00 00 00 00 00  ................
        f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    ...

The memory dump shows a 32-bit exception frame:

    x86_saved_state32

    gs = 0x37
    fs = 0
    es = 0x1f
    ds = 0x1f
    edi = 0x33a8
    esi = 0x01000000
    ebp = 0
    cr2 = 0xfedcba98
    ebx = 0x0907
    edx = 0
    ecx = 0xfedcba98
    eax = 0x06
    trapno = 0x0d
    err = 0x34
    eip = 0x1c9e
    cs = 0x17
    efl = 0x0200
    uesp = 0x30ac
    ss = 0x1f

The cr2 of 0xfedcba98 is the address that the new thread read
to cause the fault, but note that the trap is now a GP fault with
error code 0x34, meaning it's moved past the cr2 problem and on
to an invaild segment selector.  The 0x34 is suspiciously similar
to the 0x37 in gs, and sure enough, OS X forces gs to have
that value in the signal handler, and if your thread hasn't set
up that segment (known as USER_CTHREAD), you'll fault on the IRET
into the signal handler and never be able to handle a signal.

The kernel bug is that it forces segment 0x37 without making sure
it is a valid segment.  Leopard also forced 0x37 but had the courtesy
to set it up first.

Since OS X requires us to set up that segment (using the
thread_fast_set_cthread_self system call), we might as well
use it instead of the more complicated i386_set_ldt call to
set up our per-OS thread storage.

Also add some more zeros to bsdthread_register for new arguments
in Snow Leopard (apparently unnecessary, but being careful).

Fixes #510.

R=r
CC=golang-dev
https://golang.org/cl/824046

Added Signbit(), revised Copysign()

R=rsc
CC=golang-dev
https://golang.org/cl/822045

Avoids spurious wakeups during other sleeping by that goroutine.
Fixes #711.

R=r
CC=golang-dev
https://golang.org/cl/902041

Fixes #677.

R=rsc
CC=golang-dev
https://golang.org/cl/834046

R=rsc, adg
CC=golang-dev
https://golang.org/cl/881047

R=iant
CC=golang-dev
https://golang.org/cl/874043

R=rsc, iant
CC=golang-dev
https://golang.org/cl/824045

TBR=kaib
CC=golang-dev
https://golang.org/cl/897041

TBR=kaib
CC=golang-dev
https://golang.org/cl/883046

channel recv data.

R=rsc
CC=golang-dev
https://golang.org/cl/896041

data just read from the channel.
this will make it easier to
recognize when to garbage
collect and finalize.

R=rsc
CC=golang-dev
https://golang.org/cl/882043

The cycle is *netFD -> cw chanl *netFD in struct ->
same *netFD in channel read buffer.

Because channels are finalized, the cycle makes them
uncollectable.  A better fix is to make channels not
finalized anymore, and that will happen, but this is
an easy, reasonable workaround until then.

Another good fix would be to zero the channel receive
buffer entry after the receive.  That too will happen.

R=r
CC=golang-dev
https://golang.org/cl/875043

R=rsc
CC=golang-dev
https://golang.org/cl/864044

1. Fix bug in GOMAXPROCS when trying to cut number of procs
Race could happen on any system but was
manifesting only on Xen hosted Linux.

2. Fix recover on ARM, where FP != caller SP.

R=r
CC=golang-dev
https://golang.org/cl/880043

Instead of calling the package scope Lex function,
Parse now takes an argument which is used to
do the lexing.
I reverted to having the generated switch
code inside Parse rather than a separate function because
the function needs 7 arguments or a context structure,
which seems unnecessary.
I used yyrun(), not the original $A so that
it's possible to run the backquoted code through gofmt.

R=rsc, ken2, ken3
CC=golang-dev
https://golang.org/cl/879041

to float instructions work correctly.

R=rsc
CC=golang-dev
https://golang.org/cl/870044

also: add /dev/null to the ls args to repair handling of empty dependency lists.

R=rsc
CC=golang-dev
https://golang.org/cl/883045

This is a documentation enhancement only, without any code
change.

The rationale for documenting this precisely is that Unix
programmers who "know" that errno's value is undefined after
a successful system call may be surprised otherwise and
search to be sure that a zero errno may be relied upon after
successful calls.

R=r, rsc1, rsc
CC=golang-dev
https://golang.org/cl/812044

R=rsc, r
CC=golang-dev
https://golang.org/cl/810043

R=rsc
CC=golang-dev
https://golang.org/cl/812041

R=gri
CC=golang-dev
https://golang.org/cl/867044

log: add test of Caller

New regexp in log test is picky and will require some
maintenance, but it catches off-by-one mistakes too.

Fixes #710.

R=gri
CC=esko.luontola, golang-dev
https://golang.org/cl/887043

R=adg
CC=golang-dev
https://golang.org/cl/813043

R=rsc
CC=golang-dev
https://golang.org/cl/881042

Complex math function package. Still needs more special case checking.

R=rsc
CC=golang-dev
https://golang.org/cl/874041

R=iant
CC=golang-dev
https://golang.org/cl/862042

R=adg
CC=golang-dev
https://golang.org/cl/893041

R=ken2
CC=golang-dev
https://golang.org/cl/821048

R=agl1
CC=golang-dev
https://golang.org/cl/851041

  * correct symbol table size
  * do not reorder functions in output
  * traceback
  * signal handling
  * use same code for go + defer
  * handle leaf functions in symbol table

R=kaib, dpx
CC=golang-dev
https://golang.org/cl/884041

Adding this question on Russ' recommendation - not sure if
there is some detail here I'm missing.

The associated discussion was:
http://groups.google.com/group/golang-nuts/t/ec6b27e332ed7f77

R=rsc, r
CC=golang-dev
https://golang.org/cl/887042