PR bootstrap/101374
They cause a warning with the updated GCC -Warray-bounds option.
Replace them with calls to abort, which for our purposes is fine.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/333409

In newer versions of glibc it is long, which causes a signed
comparison warning.

Fixes PR go/99458

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/276153

    
    Permit putting structs with anonymous and empty fields in the C header
    file runtime.inc that is used to build the C runtime code.  This is
    required for upcoming 1.13 support, as the m struct has picked up an
    anonymous field.
    
    Doing this lets the C header contain all the type descriptor structs,
    so start using those in the C code.  This cuts the number of copies of
    type descriptor definitions from 3 to 2.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/192343

From-SVN: r275227

    
    Currently, getg is implemented in C, which loads the thread-local
    g variable. The g variable is declared static in C.
    
    This CL exposes the g variable, so it can be accessed from the Go
    side. This allows the Go compiler to inline getg calls to direct
    access of g.
    
    Currently, the actual inlining is only implemented in the gollvm
    compiler. The g variable is thread-local and the compiler backend
    may choose to cache the TLS address in a register or on stack. If
    a thread switch happens the cache may become invalid. I don't
    know how to disable the TLS address cache in gccgo, therefore
    the inlining of getg is not implemented. In the future gccgo may
    gain this if we know how to do it safely.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/186238

From-SVN: r273499

    
    These functions were needed during the transition of the runtime from
    C to Go, but are no longer necessary.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/179879

From-SVN: r271890

    
    Currently, goroutine switches are implemented with libc
    getcontext/setcontext functions, which saves/restores the machine
    register states and also the signal context. This does more than
    what we need, and performs an expensive syscall.
    
    This CL implements a simplified version of getcontext/setcontext,
    in assembly, that only saves/restores the necessary part, i.e.
    the callee-save registers, and the PC, SP. A simplified version
    of makecontext, written in C, is also added. Currently this is
    only implemented on Linux/AMD64.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178298

From-SVN: r271818

    
    This is following CL 156038. doscanstackswitch uses the same
    mechanism of switching goroutines as getTraceback, and so has
    the same problem as described in issue golang/go#29448. This CL
    applies the same fix.
    
    Reviewed-on: https://go-review.googlesource.com/c/156697

From-SVN: r267661

    
    Currently, when collecting a traceback for another goroutine,
    getTraceback calls gogo(gp) switching to gp, which will resume in
    mcall, which will call gtraceback, which will set up gp->m. There
    is a gap between setting the current running g to gp and setting
    gp->m. If a profiling signal arrives in between, sigtramp will
    see a non-nil gp with a nil m, and will seg fault. Fix this by
    setting up gp->m first.
    
    Fixes golang/go#29448.
    
    Reviewed-on: https://go-review.googlesource.com/c/156038

From-SVN: r267658

    
    This CL adds support of precise stack scan using stack maps to
    the runtime. The stack maps are generated by the compiler (if
    supported). Each safepoint is associated with a (real or dummy)
    landing pad, and its "type info" in the exception table is a
    pointer to the stack map. When a stack is scanned, the stack map
    is found by the stack unwinding code by inspecting the exception
    table (LSDA).
    
    For precise stack scan we need to unwind the stack. There are
    three cases:
    
    - If a goroutine is scanning its own stack, it can unwind the
      stack and scan the frames.
    
    - If a goroutine is scanning another, stopped, goroutine, it
      cannot directly unwind the target stack. We handle this by
      switching (runtime.gogo) to the target g, letting it unwind
      and scan the stack, and switch back.
    
    - If we are scanning a goroutine that is blocked in a syscall,
      we send a signal to the target goroutine's thread, and let the
      signal handler unwind and scan the stack. Extra care is needed
      as this races with enter/exit syscall.
    
    Currently this is only implemented on linux.
    
    Reviewed-on: https://go-review.googlesource.com/c/140518

From-SVN: r266832