summaryrefslogtreecommitdiff
path: root/src/liblink/objfile.c
Commit message (Collapse)AuthorAgeFilesLines
* [dev.cc] all: merge dev.power64 (7667e41f3ced) into dev.ccRuss Cox2014-11-141-9/+24
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to reduce the delta between dev.cc and dev.garbage to just garbage collector changes. These are the files that had merge conflicts and have been edited by hand: malloc.go mem_linux.go mgc.go os1_linux.go proc1.go panic1.go runtime1.go LGTM=austin R=austin CC=golang-codereviews https://codereview.appspot.com/174180043
| * [dev.cc] liblink: resolve bss vs other conflict regardless of order foundRuss Cox2014-11-111-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the linker finds the same name given a BSS and a non-BSS symbol, the assumption is that the non-BSS symbol is the true one, and the BSS symbol is just the best Go can do toward an "extern" declaration. This has always been the case, as long as the object files were read in the right order. The old code worked when the BSS symbol is found before the non-BSS symbol. This CL adds equivalent logic for when the non-BSS symbol is found before the BSS symbol. This comes up when Go must refer to symbols defined in host object files. LGTM=r R=r CC=austin, golang-codereviews, iant, khr https://codereview.appspot.com/171480043
* | [dev.power64] all: merge default into dev.power64Austin Clements2014-10-221-2/+7
|\ \ | |/ |/| | | | | | | | | | | | | | | | | This brings dev.power64 up-to-date with the current tip of default. go_bootstrap is still panicking with a bad defer when initializing the runtime (even on amd64). LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/152570049
| * [dev.power64] build: merge default into dev.power64Austin Clements2014-10-221-4/+14
| |\ | | | | | | | | | | | | | | | | | | LGTM=rsc R=rsc CC=golang-codereviews https://codereview.appspot.com/160200044
| * | [dev.power64] liblink: handle $i64. symbols, add debug output for -S -v, ↵Shenghou Ma2014-08-071-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | show rel addend in hex for RISC arches LGTM=rsc R=rsc, iant CC=golang-codereviews https://codereview.appspot.com/127770043
* | | liblink: fix cmd/ld -X flagRuss Cox2014-09-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the test/linkx.go test, which does not run by default. (Issue 4139 is about fixing that.) Fixes issue 8806. LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://codereview.appspot.com/145420043
* | | cmd/cc, cmd/ld, runtime: disallow conservative data/bss objectsRuss Cox2014-09-241-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In linker, refuse to write conservative (array of pointers) as the garbage collection type for any variable in the data/bss GC program. In the linker, attach the Go type to an already-read C declaration during dedup. This gives us Go types for C globals for free as long as the cmd/dist-generated Go code contains the declaration. (Most runtime C declarations have a corresponding Go declaration. Both are bss declarations and so the linker dedups them.) In cmd/dist, add a few more C files to the auto-Go-declaration list in order to get Go type information for the C declarations into the linker. In C compiler, mark all non-pointer-containing global declarations and all string data as NOPTR. This allows them to exist in C files without any corresponding Go declaration. Count C function pointers as "non-pointer-containing", since we have no heap-allocated C functions. In runtime, add NOPTR to the remaining pointer-containing declarations, none of which refer to Go heap objects. In runtime, also move os.Args and syscall.envs data into runtime-owned variables. Otherwise, in programs that do not import os or syscall, the runtime variables named os.Args and syscall.envs will be missing type information. I believe that this CL eliminates the final source of conservative GC scanning in non-SWIG Go programs, and therefore... Fixes issue 909. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/149770043
* | | liblink, sync/atomic: fix arm buildRuss Cox2014-09-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The liblink code to insert the FUNCDATA for a stack map from the Go prototype was not correct for ARM (different data structure layout). Also, sync/atomic was missing some Go prototypes for ARM-specific functions. TBR=r CC=golang-codereviews https://codereview.appspot.com/143160045
* | | liblink: make GO_ARGS the default for functions beginning with ?Russ Cox2014-09-161-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is a leading ?, assume there is a Go prototype and attach the Go prototype information to the function. If the function is not called from Go and does not need a Go prototype, it can be made file-local instead (using name<>(SB)). This fixes the current BSD build failures, by giving functions like sync/atomic.StoreUint32 argument stack map information. Fixes issue 8753. LGTM=khr, iant R=golang-codereviews, iant, khr, bradfitz CC=golang-codereviews, r, rlh https://codereview.appspot.com/142150043
* | | cmd/gc: turn Go prototypes into ptr liveness maps for assembly functionsRuss Cox2014-09-121-0/+12
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal here is to allow assembly functions to appear in the middle of a Go stack (having called other code) and still record enough information about their pointers so that stack copying and garbage collection can handle them precisely. Today, these frames are handled only conservatively. If you write func myfunc(x *float64) (y *int) (with no body, an 'extern' declaration), then the Go compiler now emits a liveness bitmap for use from the assembly definition of myfunc. The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps. The first bitmap, in effect at function entry, marks all inputs as live. The second bitmap, not in effect at function entry, marks the outputs live as well. In funcdata.h, define new assembly macros: GO_ARGS opts in to using the Go compiler-generated liveness bitmap for the current function. GO_RESULTS_INITIALIZED indicates that the results have been initialized and need to be kept live for the remainder of the function; it causes a switch to the second generated bitmap for the assembly code that follows. NO_LOCAL_POINTERS indicates that there are no pointers in the local variables being stored in the function's stack frame. LGTM=khr R=khr CC=golang-codereviews https://codereview.appspot.com/137520043
* | cmd/ld: diagnose Go calling CRuss Cox2014-08-311-4/+14
|/ | | | | | | | | | For example: go build -ldflags -C cmd/go 2>&1 | awk '{print $NF}' | sort | uniq -c | sort -nr LGTM=khr R=khr, josharian CC=golang-codereviews https://codereview.appspot.com/135170044
* liblink: use LinkArch.textflag() to get text and dataflagShenghou Ma2014-08-061-10/+2
| | | | | | | | | Rather than switch on thechar. LGTM=rsc, dave R=rsc, iant, dave CC=golang-codereviews https://codereview.appspot.com/119330043
* liblink, cmd/ld: reenable nosplit checking and testRuss Cox2014-04-161-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, cmd/gc, cmd/{5,6,8}{a,c}: rename linkwriteobj to writeobjIan Lance Taylor2014-04-161-1/+4
| | | | | | | | | | | | | The name linkwriteobj is misleading because it implies that the function has something to do with the linker, which it does not. The name is historical: the function performs an operation that was previously performed by the linker, but no longer is. LGTM=rsc R=rsc, minux.ma CC=golang-codereviews https://codereview.appspot.com/88210045
* liblink: add leaf bit to object file formatRuss Cox2014-04-161-1/+7
| | | | | | | | | | | | | | Without the leaf bit, the linker cannot record the correct frame size in the symbol table, and then stack traces get mangled. (Only for ARM.) Fixes issue 7338. Fixes issue 7347. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/88550043
* liblink: fix incorrect hash collision in lookupRuss Cox2014-04-161-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | linklookup uses hash(name, v) as the hash table index but then only compares name to find a symbol to return. If hash(name, v1) == hash(name, v2) for v1 != v2, the lookup for v2 will return the symbol with v1. The input routines assume that each symbol is found only once, and then each symbol is added to a linked list, with the list header in the symbol. Adding a symbol to such a list multiple times short-circuits the list the second time it is added, causing symbols to be dropped. The liblink rewrite introduced an elegant, if inefficient, handling of duplicated symbols by creating a dummy symbol to read the duplicate into. The dummy symbols are named .dup with sequential version numbers. With many .dup symbols, eventually there will be a conflict, causing a duplicate list add, causing elided symbols, causing a crash when calling one of the elided symbols. The bug is old (2011) but could not have manifested until the liblink rewrite introduced this heavily duplicated symbol .dup. (See History section below.) 1. Correct the lookup function. 2. Since we want all the .dup symbols to be different, there's no point in inserting them into the table. Call linknewsym directly, avoiding the lookup function entirely. 3. Since nothing can refer to the .dup symbols, do not bother adding them to the list of functions (textp) at all. 4. In lieu of a unit test, introduce additional consistency checks to detect adding a symbol to a list multiple times. This would have caught the short-circuit more directly, and it will detect a variety of double-use bugs, including the one arising from the bad lookup. Fixes issue 7749. History On April 9, 2011, I submitted CL 4383047, making ld 25% faster. Much of the focus was on the hash table lookup function, and one of the changes was to remove the s->version == v comparison [1]. I don't know if this was a simple editing error or if I reasoned that same name but different v would yield a different hash slot and so the name test alone sufficed. It is tempting to claim the former, but it was probably the latter. Because the hash is an iterated multiply+add, the version ends up adding v*3? to the hash, where n is the length of the name. A collision would need x*3? ? y*3? (mod 2?? mod 100003), or equivalently x*3? ? x*3? + (y-x)*3? (mod 2?? mod 100003), so collisions will actually be periodic: versions x and y collide when d = y-x satisfies d*3? ? 0 (mod 2?? mod 100003). Since we allocate version numbers sequentially, this is actually about the best case one could imagine: the collision rate is much lower than if the hash were more random. http://play.golang.org/p/TScD41c_hA computes the collision period for various name lengths. The most common symbol in the new linker is .dup, and for n=4 the period is maximized: the 100004th symbol is the first collision. Unfortunately, there are programs with more duplicated symbols than that. In Go 1.2 and before, duplicate symbols were handled without creating a dummy symbol, so this particular case for generating many duplicate symbols could not happen. Go does not use versioned symbols. Only C does; each input file gives a different version to its static declarations. There just aren't enough C files for this to come up in that context. So the bug is old but the realization of the bug is new. [1] https://codereview.appspot.com/4383047/diff/5001/src/cmd/ld/lib.c LGTM=minux.ma, iant, dave R=golang-codereviews, minux.ma, bradfitz, iant, dave CC=golang-codereviews, r https://codereview.appspot.com/87910047
* liblink: introduce TLS register on 386 and amd64Russ Cox2014-04-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+7
| | | | | | | | | | | | | | | | 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, cmd/link: add version number to object fileRuss Cox2014-04-141-1/+5
| | | | | | | | | | There are changes we know we want to make, but not before Go 1.3 Add a version number so that we can make them more easily later. LGTM=iant R=iant CC=golang-codereviews https://codereview.appspot.com/87670043
* cmd/gc, cmd/ld, runtime: compact liveness bitmapsRuss Cox2014-04-021-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduce footprint of liveness bitmaps by about 5x. 1. Mark all liveness bitmap symbols as 4-byte aligned (they were aligned to a larger size by default). 2. The bitmap data is a bitmap count n followed by n bitmaps. Each bitmap begins with its own count m giving the number of bits. All the m's are the same for the n bitmaps. Emit this bitmap length once instead of n times. 3. Many bitmaps within a function have the same bit values, but each call site was given a distinct bitmap. Merge duplicate bitmaps so that no bitmap is written more than once. 4. Many functions end up with the same aggregate bitmap data. We used to name the bitmap data funcname.gcargs and funcname.gclocals. Instead, name it gclocals.<md5 of data> and mark it dupok so that the linker coalesces duplicate sets. This cut the bitmap data remaining after step 3 by 40%; I was not expecting it to be quite so dramatic. Applied to "go build -ldflags -w code.google.com/p/go.tools/cmd/godoc": bitmaps pclntab binary on disk before this CL 1326600 1985854 12738268 4-byte align 1154288 (0.87x) 1985854 (1.00x) 12566236 (0.99x) one bitmap len 782528 (0.54x) 1985854 (1.00x) 12193500 (0.96x) dedup bitmap 414748 (0.31x) 1948478 (0.98x) 11787996 (0.93x) dedup bitmap set 245580 (0.19x) 1948478 (0.98x) 11620060 (0.91x) While here, remove various dead blocks of code from plive.c. Fixes issue 6929. Fixes issue 7568. LGTM=khr R=khr CC=golang-codereviews https://codereview.appspot.com/83630044
* liblink: allow either of a pair of conflicting symbols to say dupokRuss Cox2013-12-191-1/+1
| | | | | | | | This makes the linker's -X flag work again. R=iant CC=bradfitz, golang-codereviews, golang-dev https://codereview.appspot.com/44360043
* liblink: use explicit field for globl duplicate detectionRuss Cox2013-12-181-1/+2
| | | | | | | | | Overloading size leads to problems if clients try to set up an LSym by hand. R=golang-dev, bradfitz CC=golang-dev https://codereview.appspot.com/44140043
* liblink, cmd/gc: resolve several shift warningsDave Cheney2013-12-191-2/+2
| | | | | | | | Address several warnings generated by clang -fsanitize=undefined R=golang-dev, iant CC=golang-dev https://codereview.appspot.com/43050043
* liblink: rewrite '\\' in paths to '/' on windowsShenghou Ma2013-12-171-2/+33
| | | | | | | | | | | | At least three Go tests rely on that (log, runtime/{pprof,debug}). Fixes issue 6972. Fixes issue 6974. Fixes issue 6975. R=alex.brainman, mattn.jp, rsc CC=golang-dev https://codereview.appspot.com/43150043
* cmd/ld: move instruction selection + layout into compilers, assemblersRuss Cox2013-12-161-0/+665
- 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
View Lorry Controller Status