Fourth time's the charm.
Actually this doesn't fix the build, there is a
crash after go_bootstrap is compiled which looks
like it is related to auxv parsing.
Change-Id: Id00e2dfbe7bae42856f996065d3fb90b820e29a8
Reviewed-on: https://go-review.googlesource.com/3610
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Another attempt to fix the arm build by moving the include of signal.h
to cmd/lex.c, unless we are building on plan9.
Obviously if we had a plan9/arm builder this would probably not work, but
this is only a temporary measure until the c2go transition is complete.
Change-Id: I7f8ae27349b2e7a09c55db03e02a01939159a268
Reviewed-on: https://go-review.googlesource.com/3566
Reviewed-by: Russ Cox <rsc@golang.org>
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
. By defining getcallerpc(x) as __builtin_return_address(0)
here, it becomes possible to use the Plan 9 compatible form
when compiling using GCC. The alternative is to add conditional
compilation based on the compiler identity in "cmd/8g/gsubr.c"
to distinguish between the two cases.
R=golang-dev
CC=golang-dev, rsc
https://golang.org/cl/4800048
The "elf.h" header changes involve only comments, the released
Plan 9 C preprocessing function does not cope with multiline
comments following the #define keyword. All multiline comments
have been moved to the line above the associated definition.
Sigh! Fixing the Plan 9 compiler is not an option.
<time.h> does not exist in the Plan 9 Native library. I have
moved it from src/cmd/ld/pe.h to include/u.h. RSC correctly points
out that this copy of <u.h> is not the one used to compile the
Go release on Plan 9 platforms.
R=golang-dev
CC=golang-dev, rsc
https://golang.org/cl/4574042
these guys really really want long to be 32-bits,
so ,s/long/int32/ (and then manual fixup).
still passes all tests.
(i started out looking for just those longs that
needed to be int32 instead, and it was just too hard
to track them down one by one.)
the longs were rare enough that i don't think
it will cause integration problems.
R=ken
OCL=13787
CL=13789
