summaryrefslogtreecommitdiff
path: root/src/liblink/obj6.c
Commit message (Collapse)AuthorAgeFilesLines
* runtime: assume precisestack, copystack, StackCopyAlways, ScanStackByFramesRuss Cox2014-09-091-170/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit to stack copying for stack growth. We're carrying around a surprising amount of cruft from older schemes. I am confident that precise stack scans and stack copying are here to stay. Delete fallback code for when precise stack info is disabled. Delete fallback code for when copying stacks is disabled. Delete fallback code for when StackCopyAlways is disabled. Delete Stktop chain - there is only one stack segment now. Delete M.moreargp, M.moreargsize, M.moreframesize, M.cret. Delete G.writenbuf (unrelated, just dead). Delete runtime.lessstack, runtime.oldstack. Delete many amd64 morestack variants. Delete initialization of morestack frame/arg sizes (shortens split prologue!). Replace G's stackguard/stackbase/stack0/stacksize/ syscallstack/syscallguard/forkstackguard with simple stack bounds (lo, hi). Update liblink, runtime/cgo for adjustments to G. LGTM=khr R=khr, bradfitz CC=golang-codereviews, iant, r https://codereview.appspot.com/137410043
* liblink, runtime: diagnose and fix C code running on Go stackRuss Cox2014-09-081-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL contains compiler+runtime changes that detect C code running on Go (not g0, not gsignal) stacks, and it contains corrections for what it detected. The detection works by changing the C prologue to use a different stack guard word in the G than Go prologue does. On the g0 and gsignal stacks, that stack guard word is set to the usual stack guard value. But on ordinary Go stacks, that stack guard word is set to ^0, which will make any stack split check fail. The C prologue then calls morestackc instead of morestack, and morestackc aborts the program with a message about running C code on a Go stack. This check catches all C code running on the Go stack except NOSPLIT code. The NOSPLIT code is allowed, so the check is complete. Since it is a dynamic check, the code must execute to be caught. But unlike the static checks we've been using in cmd/ld, the dynamic check works with function pointers and other indirect calls. For example it caught sigpanic being pushed onto Go stacks in the signal handlers. Fixes issue 8667. LGTM=khr, iant R=golang-codereviews, khr, iant CC=golang-codereviews, r https://codereview.appspot.com/133700043
* build: adjustments for move from src/pkg to srcRuss Cox2014-09-081-1/+1
| | | | | | | | | | | | | | | | | | | This CL adjusts code referring to src/pkg to refer to src. Immediately after submitting this CL, I will submit a change doing 'hg mv src/pkg/* src'. That change will be too large to review with Rietveld but will contain only the 'hg mv'. This CL will break the build. The followup 'hg mv' will fix it. For more about the move, see golang.org/s/go14nopkg. LGTM=r R=r CC=golang-codereviews https://codereview.appspot.com/134570043
* runtime: fix nacl/amd64p32 buildRuss Cox2014-09-071-0/+22
| | | | | | | | | Update issue 8675 Fixes nacl/amd64p32 build. TBR=khr CC=golang-codereviews https://codereview.appspot.com/141140045
* runtime: fix panic/wrapper/recover mathRuss Cox2014-09-061-20/+58
| | | | | | | | | | | | | | | | | | The gp->panicwrap adjustment is just fatally flawed. Now that there is a Panic.argp field, update that instead. That can be done on entry only, so that unwinding doesn't need to worry about undoing anything. The wrappers emit a few more instructions in the prologue but everything else in the system gets much simpler. It also fixes (without trying) a broken test I never checked in. Fixes issue 7491. LGTM=khr R=khr CC=dvyukov, golang-codereviews, iant, r https://codereview.appspot.com/135490044
* liblink: support big-endian properlyShenghou Ma2014-08-061-0/+2
| | | | | | | LGTM=rsc R=rsc, iant CC=golang-codereviews https://codereview.appspot.com/115300044
* build: annotations and modifications for c2goRuss Cox2014-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The main changes fall into a few patterns: 1. Replace #define with enum. 2. Add /*c2go */ comment giving effect of #define. This is necessary for function-like #defines and non-enum-able #defined constants. (Not all compilers handle negative or large enums.) 3. Add extra braces in struct initializer. (c2go does not implement the full rules.) This is enough to let c2go typecheck the source tree. There may be more changes once it is doing other semantic analyses. LGTM=minux, iant R=minux, dave, iant CC=golang-codereviews https://codereview.appspot.com/106860045
* liblink, runtime: preliminary support for plan9/amd64Aram H?v?rneanu2014-07-021-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | A TLS slot is reserved by _rt0_.*_plan9 as an automatic and its address (which is static on Plan 9) is saved in the global _privates symbol. The startup linkage now is exactly like that from Plan 9 libc, and the way we access g is exactly as if we'd have used privalloc(2). Aside from making the code more standard, this change drastically simplifies it, both for 386 and for amd64, and makes the Plan 9 code in liblink common for both 386 and amd64. The amd64 runtime code was cleared of nxm assumptions, and now runs on the standard Plan 9 kernel. Note handling fixes will follow in a separate CL. LGTM=rsc R=golang-codereviews, rsc, bradfitz, dave CC=0intro, ality, golang-codereviews, jas, minux.ma, mischief https://codereview.appspot.com/101510049 Committer: Dave Cheney <dave@cheney.net>
* all: remove 'extern register M *m' from runtimeRuss Cox2014-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The runtime has historically held two dedicated values g (current goroutine) and m (current thread) in 'extern register' slots (TLS on x86, real registers backed by TLS on ARM). This CL removes the extern register m; code now uses g->m. On ARM, this frees up the register that formerly held m (R9). This is important for NaCl, because NaCl ARM code cannot use R9 at all. The Go 1 macrobenchmarks (those with per-op times >= 10 ?s) are unaffected: BenchmarkBinaryTree17 5491374955 5471024381 -0.37% BenchmarkFannkuch11 4357101311 4275174828 -1.88% BenchmarkGobDecode 11029957 11364184 +3.03% BenchmarkGobEncode 6852205 6784822 -0.98% BenchmarkGzip 650795967 650152275 -0.10% BenchmarkGunzip 140962363 141041670 +0.06% BenchmarkHTTPClientServer 71581 73081 +2.10% BenchmarkJSONEncode 31928079 31913356 -0.05% BenchmarkJSONDecode 117470065 113689916 -3.22% BenchmarkMandelbrot200 6008923 5998712 -0.17% BenchmarkGoParse 6310917 6327487 +0.26% BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17% BenchmarkRegexpMatchHard_1K 168977 169244 +0.16% BenchmarkRevcomp 935294971 914060918 -2.27% BenchmarkTemplate 145917123 148186096 +1.55% Minux previous reported larger variations, but these were caused by run-to-run noise, not repeatable slowdowns. Actual code changes by Minux. I only did the docs and the benchmarking. LGTM=dvyukov, iant, minux R=minux, josharian, iant, dave, bradfitz, dvyukov CC=golang-codereviews https://codereview.appspot.com/109050043
* liblink, cmd/ld: reenable nosplit checking and testRuss Cox2014-04-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The new code is adapted from the Go 1.2 nosplit code, but it does not have the bug reported in issue 7623: g% go run nosplit.go g% go1.2 run nosplit.go BUG rejected incorrectly: main 0 call f; f 120 linker output: # _/tmp/go-test-nosplit021064539 main.main: nosplit stack overflow 120 guaranteed after split check in main.main 112 on entry to main.f -8 after main.f uses 120 g% Fixes issue 6931. Fixes issue 7623. LGTM=iant R=golang-codereviews, iant, ality CC=golang-codereviews, r https://codereview.appspot.com/88190043
* liblink: introduce TLS register on 386 and amd64Russ Cox2014-04-151-128/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 issue 7164. LGTM=iant R=iant, aram, minux.ma, dave CC=golang-codereviews https://codereview.appspot.com/87920043
* liblink: remove arch-specific constants from file formatRuss Cox2014-04-141-4/+4
| | | | | | | | | | | | | | | | The relocation and automatic variable types were using arch-specific numbers. Introduce portable enumerations instead. To the best of my knowledge, these are the only arch-specific bits left in the new object file format. Remove now, before Go 1.3, because file formats are forever. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/87670044
* liblink: fix morestack handling on amd64p32.R?my Oudompheng2014-03-071-1/+2
| | | | | | | | | | It was using MOVL to pass a 64-bit argument (concatenated framesize and argsize) to morestack11. LGTM=dave, rsc R=dave, rsc, iant CC=golang-codereviews https://codereview.appspot.com/72360044
* cmd/ld: clear unused ctxt before morestackRuss Cox2014-03-041-8/+18
| | | | | | | | | | | | | | | | | | 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 issue 7244. LGTM=dvyukov R=khr, dvyukov CC=golang-codereviews https://codereview.appspot.com/71030044
* all: final merge of NaCl treeRuss Cox2014-02-271-25/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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://codereview.appspot.com/15750044 --- LGTM=bradfitz, dave, iant R=dave, bradfitz, iant CC=golang-codereviews https://codereview.appspot.com/69040044
* include, linlink, cmd/6l, cmd/ld: part 1 of solaris/amd64 linker changes.Shenghou Ma2014-02-091-2/+4
| | | | | | | | | | 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://codereview.appspot.com/54210050
* liblink: fix Plan 9 warningsDavid du Colombier2013-12-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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://codereview.appspot.com/40370043
* cmd/ld: move instruction selection + layout into compilers, assemblersRuss Cox2013-12-161-142/+127
| | | | | | | | | | | | | | | | | | | | | - 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://codereview.appspot.com/39680043
* cmd/6l: fix linux/amd64Russ Cox2013-12-091-9/+7
| | | | | | TBR=iant CC=golang-dev https://codereview.appspot.com/39530043
* liblink: create new library based on linker codeRuss Cox2013-12-081-0/+1078
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://codereview.appspot.com/35790044