An error occurred fetching the project authors.
  1. 15 Apr, 2014 1 commit
    • Russ Cox's avatar
      liblink: introduce TLS register on 386 and amd64 · 90093f06
      Russ Cox authored
      When I did the original 386 ports on Linux and OS X, I chose to
      define GS-relative expressions like 4(GS) as relative to the actual
      thread-local storage base, which was usually GS but might not be
      (it might be FS, or it might be a different constant offset from GS or FS).
      
      The original scope was limited but since then the rewrites have
      gotten out of control. Sometimes GS is rewritten, sometimes FS.
      Some ports do other rewrites to enable shared libraries and
      other linking. At no point in the code is it clear whether you are
      looking at the real GS/FS or some synthesized thing that will be
      rewritten. The code manipulating all these is duplicated in many
      places.
      
      The first step to fixing issue 7719 is to make the code intelligible
      again.
      
      This CL adds an explicit TLS pseudo-register to the 386 and amd64.
      As a register, TLS refers to the thread-local storage base, and it
      can only be loaded into another register:
      
              MOVQ TLS, AX
      
      An offset from the thread-local storage base is written off(reg)(TLS*1).
      Semantically it is off(reg), but the (TLS*1) annotation marks this as
      indexing from the loaded TLS base. This emits a relocation so that
      if the linker needs to adjust the offset, it can. For example:
      
              MOVQ TLS, AX
              MOVQ 8(AX)(TLS*1), CX // load m into CX
      
      On systems that support direct access to the TLS memory, this
      pair of instructions can be reduced to a direct TLS memory reference:
      
              MOVQ 8(TLS), CX // load m into CX
      
      The 2-instruction and 1-instruction forms correspond roughly to
      ELF TLS initial exec mode and ELF TLS local exec mode, respectively.
      
      Liblink applies this rewrite on systems that support the 1-instruction form.
      The decision is made using only the operating system (and probably
      the -shared flag, eventually), not the link mode. If some link modes
      on a particular operating system require the 2-instruction form,
      then all builds for that operating system will use the 2-instruction
      form, so that the link mode decision can be delayed to link time.
      
      Obviously it is late to be making changes like this, but I despair
      of correcting issue 7719 and issue 7164 without it. To make sure
      I am not changing existing behavior, I built a "hello world" program
      for every GOOS/GOARCH combination we have and then worked
      to make sure that the rewrite generates exactly the same binaries,
      byte for byte. There are a handful of TODOs in the code marking
      kludges to get the byte-for-byte property, but at least now I can
      explain exactly how each binary is handled.
      
      The targets I tested this way are:
      
              darwin-386
              darwin-amd64
              dragonfly-386
              dragonfly-amd64
              freebsd-386
              freebsd-amd64
              freebsd-arm
              linux-386
              linux-amd64
              linux-arm
              nacl-386
              nacl-amd64p32
              netbsd-386
              netbsd-amd64
              openbsd-386
              openbsd-amd64
              plan9-386
              plan9-amd64
              solaris-amd64
              windows-386
              windows-amd64
      
      There were four exceptions to the byte-for-byte goal:
      
      windows-386 and windows-amd64 have a time stamp
      at bytes 137 and 138 of the header.
      
      darwin-386 and plan9-386 have five or six modified
      bytes in the middle of the Go symbol table, caused by
      editing comments in runtime/sys_{darwin,plan9}_386.s.
      
      Fixes #7164.
      
      LGTM=iant
      R=iant, aram, minux.ma, dave
      CC=golang-codereviews
      https://golang.org/cl/87920043
      90093f06
  2. 14 Apr, 2014 1 commit
  3. 07 Mar, 2014 1 commit
  4. 04 Mar, 2014 1 commit
    • Russ Cox's avatar
      cmd/ld: clear unused ctxt before morestack · c2dd33a4
      Russ Cox authored
      For non-closure functions, the context register is uninitialized
      on entry and will not be used, but morestack saves it and then the
      garbage collector treats it as live. This can be a source of memory
      leaks if the context register points at otherwise dead memory.
      Avoid this by introducing a parallel set of morestack functions
      that clear the context register, and use those for the non-closure functions.
      
      I hope this will help with some of the finalizer flakiness, but it probably won't.
      
      Fixes #7244.
      
      LGTM=dvyukov
      R=khr, dvyukov
      CC=golang-codereviews
      https://golang.org/cl/71030044
      c2dd33a4
  5. 28 Feb, 2014 1 commit
    • Russ Cox's avatar
      all: final merge of NaCl tree · d9c6ae6a
      Russ Cox authored
      This CL replays the following one CL from the rsc-go13nacl repo.
      This is the last replay CL: after this CL the main repo will have
      everything the rsc-go13nacl repo did. Changes made to the main
      repo after the rsc-go13nacl repo branched off probably mean that
      NaCl doesn't actually work after this CL, but all the code is now moved
      over and just needs to be redebugged.
      
      ---
      cmd/6l, cmd/8l, cmd/ld: support for Native Client
      
      See golang.org/s/go13nacl for design overview.
      
      This CL is publicly visible but not CC'ed to golang-dev,
      to avoid distracting from the preparation of the Go 1.2
      release.
      
      This CL and the others will be checked into my rsc-go13nacl
      clone repo for now, and I will send CLs against the main
      repo early in the Go 1.3 development.
      
      R≡khr
      https://golang.org/cl/15750044
      ---
      
      LGTM=bradfitz, dave, iant
      R=dave, bradfitz, iant
      CC=golang-codereviews
      https://golang.org/cl/69040044
      d9c6ae6a
  6. 09 Feb, 2014 1 commit
  7. 18 Dec, 2013 1 commit
    • David du Colombier's avatar
      liblink: fix Plan 9 warnings · 6e975130
      David du Colombier authored
      warning: src/liblink/asm5.c:485 non-interruptable temporary
      warning: src/liblink/asm5.c:565 set and not used: c
      warning: src/liblink/asm5.c:622 format mismatch ux VLONG, arg 2
      warning: src/liblink/asm5.c:1218 overspecified class: asmout GLOBL STATIC
      warning: src/liblink/asm5.c:2088 overspecified class: oprrr GLOBL STATIC
      warning: src/liblink/asm5.c:2202 overspecified class: opbra GLOBL STATIC
      warning: src/liblink/asm5.c:2237 overspecified class: olr GLOBL STATIC
      warning: src/liblink/asm5.c:2266 overspecified class: olhr GLOBL STATIC
      warning: src/liblink/asm5.c:2291 overspecified class: osr GLOBL STATIC
      warning: src/liblink/asm5.c:2302 overspecified class: oshr GLOBL STATIC
      warning: src/liblink/asm5.c:2312 overspecified class: osrr GLOBL STATIC
      warning: src/liblink/asm5.c:2319 overspecified class: oshrr GLOBL STATIC
      warning: src/liblink/asm5.c:2325 overspecified class: olrr GLOBL STATIC
      warning: src/liblink/asm5.c:2332 overspecified class: olhrr GLOBL STATIC
      warning: src/liblink/asm5.c:2338 overspecified class: ofsr GLOBL STATIC
      warning: src/liblink/asm5.c:2375 overspecified class: omvl GLOBL STATIC
      warning: src/liblink/asm8.c:1261 format mismatch d VLONG, arg 3
      warning: src/liblink/asm8.c:1274 format mismatch +d VLONG, arg 5
      warning: src/liblink/list5.c:153 format mismatch d VLONG, arg 3
      warning: src/liblink/list5.c:310 format mismatch d VLONG, arg 3
      warning: src/liblink/obj6.c:665 set and not used: q
      warning: src/liblink/pcln.c:32 set and not used: p
      
      R=golang-dev, jas, gobot, rsc
      CC=golang-dev
      https://golang.org/cl/40370043
      6e975130
  8. 16 Dec, 2013 1 commit
    • Russ Cox's avatar
      cmd/ld: move instruction selection + layout into compilers, assemblers · a9f6db58
      Russ Cox authored
      - new object file reader/writer (liblink/objfile.c)
      - remove old object file writing routines
      - add pcdata iterator
      - remove all trace of "line number stack" and "path fragments" from
        object files, linker (!!!)
      - dwarf now writes a single "compilation unit" instead of one per package
      
      This CL disables the check for chains of no-split functions that
      could overflow the stack red zone. A future CL will attack the problem
      of reenabling that check (issue 6931).
      
      This CL is just the liblink and cmd/ld changes.
      There are minor associated adjustments in CL 37030045.
      Each depends on the other.
      
      R=golang-dev, dave, iant
      CC=golang-dev
      https://golang.org/cl/39680043
      a9f6db58
  9. 09 Dec, 2013 2 commits
    • Russ Cox's avatar
      cmd/6l: fix linux/amd64 · 1eac128d
      Russ Cox authored
      TBR=iant
      CC=golang-dev
      https://golang.org/cl/39530043
      1eac128d
    • Russ Cox's avatar
      liblink: create new library based on linker code · 7d507dc6
      Russ Cox authored
      There is an enormous amount of code moving around in this CL,
      but the code is the same, and it is invoked in the same ways.
      This CL is preparation for the new linker structure, not the new
      structure itself.
      
      The new library's definition is in include/link.h.
      
      The main change is the use of a Link structure to hold all the
      linker-relevant state, replacing the smattering of global variables.
      The Link structure should both make it clearer which state must
      be carried around and make it possible to parallelize more easily
      later.
      
      The main body of the linker has moved into the architecture-independent
      cmd/ld directory. That includes the list of known header types, so the
      distinction between Hplan9x32 and Hplan9x64 is removed (no other
      header type distinguished 32- and 64-bit formats), and code for unused
      formats such as ipaq kernels has been deleted.
      
      The code being deleted from 5l, 6l, and 8l reappears in liblink or in ld.
      Because multiple files are being merged in the liblink directory,
      it is not possible to show the diffs nicely in hg.
      
      The Prog and Addr structures have been unified into an
      architecture-independent form and moved to link.h, where they will
      be shared by all tools: the assemblers, the compilers, and the linkers.
      The unification makes it possible to write architecture-independent
      traversal of Prog lists, among other benefits.
      
      The Sym structures cannot be unified: they are too fundamentally
      different between the linker and the compilers. Instead, liblink defines
      an LSym - a linker Sym - to be used in the Prog and Addr structures,
      and the linker now refers exclusively to LSyms. The compilers will
      keep using their own syms but will fill out the corresponding LSyms in
      the Prog and Addr structures.
      
      Although code from 5l, 6l, and 8l is now in a single library, the
      code has been arranged so that only one architecture needs to
      be linked into a particular program: 5l will not contain the code
      needed for x86 instruction layout, for example.
      
      The object file writing code in liblink/obj.c is from cmd/gc/obj.c.
      
      Preparation for golang.org/s/go13linker work.
      
      This CL does not build by itself. It depends on 35740044
      and will be submitted at the same time.
      
      R=iant
      CC=golang-dev
      https://golang.org/cl/35790044
      7d507dc6