1
0
mirror of https://github.com/golang/go synced 2024-10-02 14:28:38 -06:00
Commit Graph

6 Commits

Author SHA1 Message Date
Shenghou Ma
6ebf59b953 include, linlink, cmd/6l, cmd/ld: part 1 of solaris/amd64 linker changes.
rsc suggested that we split the whole linker changes into three parts.
This is the first one, mostly dealing with adding Hsolaris.

LGTM=iant
R=golang-codereviews, iant, dave
CC=golang-codereviews
https://golang.org/cl/54210050
2014-02-09 16:45:38 -05:00
Ian Lance Taylor
6111dc4e71 liblink: check for symgrow size too large
Many calls to symgrow pass a vlong value.  Change the function
to not implicitly truncate, and to instead give an error if
the value is too large.

R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/54010043
2014-01-21 06:12:54 -08:00
Russ Cox
4890502af6 liblink: use explicit field for globl duplicate detection
Overloading size leads to problems if clients
try to set up an LSym by hand.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/44140043
2013-12-18 19:36:14 -05:00
Russ Cox
a9f6db58ce cmd/ld: move instruction selection + layout into compilers, assemblers
- 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
2013-12-16 12:51:58 -05:00
David du Colombier
4321beba85 liblink, cmd/gc: fix incompatible type signatures on Plan 9
R=ality, golang-dev, r, rsc
CC=golang-dev
https://golang.org/cl/39640043
2013-12-10 08:42:41 -05:00
Russ Cox
7d507dc6e6 liblink: create new library based on linker code
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
2013-12-08 22:49:37 -05:00