Skip to content

G
golang
Switch branch/tag
  1. 14 Nov, 2015 11 commits
  3. 13 Nov, 2015 24 commits
  5. 12 Nov, 2015 5 commits
    • Michael Hudson-Doyle's avatar
      cmd/go, cmd/link: enable -buildmode=shared on linux/ppc64le · 9a476028
      Michael Hudson-Doyle authored 
      Change-Id: Ifba76413b8aa78a221385bf505b92a3a5fbc3d24
Reviewed-on: https://go-review.googlesource.com/16713Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      9a476028
    • Michael Hudson-Doyle's avatar
      cmd/internal/obj, runtime: implement IE model TLS on ppc64le · a35c85c0
      Michael Hudson-Doyle authored 
      This requires changing the tls access code to match the patterns documented in
the ABI documentation or the system linker will "optimize" it into ridiculousness.

With this change, -buildmode=pie works, although as it is tested in testshared,
the tests are not run yet.

Change-Id: I1efa6687af0a5b8db3385b10f6542a49056b2eb3
Reviewed-on: https://go-review.googlesource.com/15971Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      a35c85c0
    • Michael Hudson-Doyle's avatar
      cmd/internal/obj, cmd/link: generate position independent loads of static data · bd329d47
      Michael Hudson-Doyle authored 
      Change-Id: I0a8448c2b69f5cfa6f099d772f5eb3412f853045
Reviewed-on: https://go-review.googlesource.com/15969Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      bd329d47
    • Michael Hudson-Doyle's avatar
      cmd/compile, cmd/link, runtime: on ppc64x, maintain the TOC pointer in R2 when compiling PIC · 368d5484
      Michael Hudson-Doyle authored 
      The PowerPC ISA does not have a PC-relative load instruction, which poses
obvious challenges when generating position-independent code. The way the ELFv2
ABI addresses this is to specify that r2 points to a per "module" (shared
library or executable) TOC pointer. Maintaining this pointer requires
cooperation between codegen and the system linker:

 * Non-leaf functions leave space on the stack at r1+24 to save the TOC pointer.
 * A call to a function that *might* have to go via a PLT stub must be followed
   by a nop instruction that the system linker can replace with "ld r1, 24(r1)"
   to restore the TOC pointer (only when dynamically linking Go code).
 * When calling a function via a function pointer, the address of the function
   must be in r12, and the first couple of instructions (the "global entry
   point") of the called function use this to derive the address of the TOC
   for the module it is in.
 * When calling a function that is implemented in the same module, the system
   linker adjusts the call to skip over the instructions mentioned above (the
   "local entry point"), assuming that r2 is already correctly set.

So this changeset adds the global entry point instructions, sets the metadata so
the system linker knows where the local entry point is, inserts code to save the
TOC pointer at 24(r1), adds a nop after any call not known to be local and copes
with the odd non-local code transfer in the runtime (e.g. the stuff around
jmpdefer). It does not actually compile PIC yet.

Change-Id: I7522e22bdfd2f891745a900c60254fe9e372c854
Reviewed-on: https://go-review.googlesource.com/15967Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      368d5484
    • Matthew Dempsky's avatar
      runtime: update newosproc asm to access m.id directly · dbdd8c2c
      Matthew Dempsky authored 
      darwin/386, freebsd/386, and linux/386 use a setldt system call to
setup each M's thread-local storage area, and they need access to the
M's id for this.  The current code copies m.id into m.tls[0] (and this
logic has been cargo culted to OSes like NetBSD and OpenBSD, which
don't even need m.id to configure TLS), and then the 386 assembly
loads m.tls[0]... but since the assembly code already has a pointer to
the M, it might as well just load m.id directly.

Change-Id: I1a7278f1ec8ebda8d1de3aa3a61993070e3a8cdf
Reviewed-on: https://go-review.googlesource.com/16881
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      dbdd8c2c