Not sure how I managed to do this, or get it past review.
Change-Id: I141b97ef8e09dcc9c910c45493a584a3dced2b28
Reviewed-on: https://go-review.googlesource.com/14634
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
this leaves lots of cruft behind, will delete that soon
Change-Id: I12d6b6192f89bcdd89b2b0873774bd3458373b8a
Reviewed-on: https://go-review.googlesource.com/14196
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also run testcshared.
Fixes#12425
Change-Id: I5baea8d772d3462f945aab96260b4197dbb20c0a
Reviewed-on: https://go-review.googlesource.com/14143
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently Go produces shared libraries that cannot be shared between processes
because they have relocations against the text segment (not text section). This
fixes this by moving some data to sections with magic names recognized by the
static linker.
The change in genasmsym to add STYPELINK to the switch should fix things on
darwin/arm64.
Fixes#10914
Updates #9210
Change-Id: Iab4a6678dd04cec6114e683caac5cf31b1063309
Reviewed-on: https://go-review.googlesource.com/14306
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestNoteReading fails on Solaris with linkmode=external due to some
assumptions made about how ELF .note sections are written by some
linkers.
On current versions of Solaris and older derivatives, SHF_ALLOC is
intentionally ignored for .note sections unless the .note section is
assigned to the text segment via a mapfile. Also, if .note sections
are assigned to the text segment, no PT_NOTE program header will be
created thwarting Go's attempts at attempting to quickly find the
.note.
Furthermore, Go assumes that the relevant note segment will be placed
early in the file while the Solaris linker currently places the note
segment last in the file, additionally thwarting Go's optimisation
attempts that read only the first 16KB of the file to find the
buildid.
The fix is to detect when the note section is outside of the first
16KB of the file and then fallback to additionally reading that
section of the file. This way, in future versions of Solaris when
this linking behaviour is changed, the fast path will always succeed
and we'll only be slower if it fails; likewise, any other linker that
does this will also just work.
Fixes#12178
Change-Id: I61c1dc3f744ae3ad63938386d2ace8a432c0efe1
Reviewed-on: https://go-review.googlesource.com/14210
Run-TryBot: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
This reverts commit 2c2cbb69c8.
Broke darwin/arm64
Change-Id: Ibd2dea475d6ce6a8b4b40e2da19a83fc0514025d
Reviewed-on: https://go-review.googlesource.com/14301
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some symbols, for example, masks requires 16-byte alignment, and
they are placed in the text section. Before this change, the text
section is only aligned to 4-byte, and it's making masks unaligned.
Fixes#12415.
Change-Id: I7767778d1b4f7d3e74c2719a02848350782a4160
Reviewed-on: https://go-review.googlesource.com/14166
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently Go produces shared libraries that cannot be shared between processes
because they have relocations against the text segment (not text section). This
fixes this by moving some data to sections with magic names recognized by the
static linker.
Fixes#10914
Updates #9210
Change-Id: I7178daadc0ae87953d5a084aa3d580f4e3b46d47
Reviewed-on: https://go-review.googlesource.com/10300
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
And do it properly so freebsd and nacl still work.
Change-Id: I6f9f30e93ceae6dee59215ed608c6a158bdbdbb0
Reviewed-on: https://go-review.googlesource.com/14280
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also simplifies some silliness around making the .tbss section wrt internal
vs external linking. The "make TLS make sense" project has quite a few more
steps to go.
Issue #11270
Change-Id: Ia4fa135cb22d916728ead95bdbc0ebc1ae06f05c
Reviewed-on: https://go-review.googlesource.com/13990
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
And clean up the mess on arm64 (the mess on arm is too confusing).
See issue #10050
Change-Id: I2ce813fe8646d4e818eb660612a7e4b2bb04de4c
Reviewed-on: https://go-review.googlesource.com/13884
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No longer used after previous hashmap change.
Change-Id: I558470f872281e84a78406132df4e391d077b833
Reviewed-on: https://go-review.googlesource.com/13785
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This was always a bit confusing, but it also fixes a problem: runtime.firstmoduledata
was always overridden in the linker to be a local symbol but cmd/internal/obj had
already rewritten code accessing it to access it via the GOT. This works on amd64, but
causes link failures on other platforms (e.g. arm64).
Change-Id: I9b8153af74b4d0f092211d63a000d15818f39773
Reviewed-on: https://go-review.googlesource.com/13786
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The nosplit stack overflow checks were confused about morestack.
The comment about not having correct SP information at the call
to morestack was true, but that was a real bug, not something to
work around. I fixed that problem in CL 12144. With that fixed,
no need to special-case morestack in the way done here.
This cleanup and simplification of the code was the first step
to fixing a bug that happened when I started working on the
arm64 frame size adjustments, but the cleanup was sufficient
to make the bug go away.
For #9880.
Change-Id: I16b69a5c16b6b8cb4090295d3029c42d606e3b9b
Reviewed-on: https://go-review.googlesource.com/12846
Reviewed-by: Austin Clements <austin@google.com>
On Windows, gcc -o foo will generate foo.exe. Prevent that from
happening by adding a final '.' if necessary so that GCC thinks that
the file already has an extension.
Also remove the initial output file when doing an external link, and
use mayberemoveoutfile, not os.Remove, when building an archive
(otherwise we will do the wrong thing for -buildmode=c-archive -o
/dev/null).
I didn't add a test, as it requires using cgo and -o on Windows.
Fixes#11725.
Change-Id: I6ea12437bb6b4b9b8ee5c3b52d83509fa2437b2d
Reviewed-on: https://go-review.googlesource.com/12243
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Same as we do for string symbols.
Fixes#11583.
Change-Id: Ia9264f6faf486697d987051b7f9851d37d8ad381
Reviewed-on: https://go-review.googlesource.com/12531
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
Instead of silently truncating integers to their expected range, check
that they're within range and emit errors if not. Intended to help
narrow down the cause of issue #11617.
Change-Id: Ia7b577270f8438ca7479262702371e26277f1ea7
Reviewed-on: https://go-review.googlesource.com/12050
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We can't address more than this on amd64 anyway.
Fixes#9862.
Change-Id: Ifb1abae558e2e1ee2dc953a76995f3f08c60b1df
Reviewed-on: https://go-review.googlesource.com/11715
Reviewed-by: Austin Clements <austin@google.com>
This code used to only be run for ELF, with the predictable
result that using -s with external linking broke on Windows and OS X.
Moving it here should fix Windows and does fix OS X.
CL 10835 also claims to fix the crash on Windows.
I don't know whether it does so correctly, but regardless,
this CL should make that one a no-op.
Fixes#10254.
Change-Id: I2e7b45ab0c28568ddbb1b50581dcc157ae0e7ffe
Reviewed-on: https://go-review.googlesource.com/11695
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The old code was recording the current table output offset,
so the table from the next function would be used instead of
the runtime realizing that there was no table at all.
Add debug constant in runtime to check this for every function
at startup. It's too expensive to do that by default, but we can
do the last five functions. The end of the table is usually where
the C symbols end up, so that's where the problems typically are.
Fixes#10747.
Fixes#11396.
Change-Id: I13592e78017969fc22979fa902e19e1b151d41b1
Reviewed-on: https://go-review.googlesource.com/11657
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
It looks like the test for whether symbols contain subsymbols is wrong.
In particular, symbols in C libraries are mistakenly considered container
symbols.
Fix the test so only symbols which actually have a subsymbol
are excluded from the symtab. When linking cgo programs the list
of containers is small, something like:
container _/home/khr/sandbox/symtab/misc/cgo/test(.text)<74>
container _/home/khr/sandbox/symtab/misc/cgo/test/issue8828(.text)<75>
container _/home/khr/sandbox/symtab/misc/cgo/test/issue9026(.text)<76>
container runtime/cgo(.text)<77>
I'm not sure this is the right fix. In particular I can't reproduce
the original problem. Anyone have a repro they can try and see if
this fix works?
Fixes#10747Fixes#11396
Change-Id: Id8b016389d33348b4a791fdcba0f9db8ae71ebf3
Reviewed-on: https://go-review.googlesource.com/11652
Reviewed-by: Russ Cox <rsc@golang.org>
Partial revert of cl/10284 to get -buildmode=c-archive working for
darwin/arm.
Manually tested with iostest.bash while builder is offline.
Change-Id: I98e4e209765666e320e680e11151fce59e2afde9
Reviewed-on: https://go-review.googlesource.com/11306
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
All of the heavy-lifting was done by minux@, with his external-linking support
for darwin/arm64: golang.org/cl/8781
Change-Id: I7c9fbc19246f418c065c92fb2c13c00026ff0f82
Reviewed-on: https://go-review.googlesource.com/11127
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes the behaviour match what happens when duplicate symbols are read
from regular object files and fixes errors about cgoAlwaysFalse when linking
an executable that uses cgo against a shared library.
Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063
Reviewed-on: https://go-review.googlesource.com/11117
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: If11621985c0a5a1f2133cdc974f37fd944b93e5e
Reviewed-on: https://go-review.googlesource.com/10808
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also fix the interaction between -buildmode and -shared.
It's okay for -shared to change the default build mode,
but it's not okay for it to silently override an explicit -buildmode=exe.
Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba
Reviewed-on: https://go-review.googlesource.com/10315
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
People invoking the linker directly already have to change their scripts
to use the new "go tool link", so this is a good time to make the -X flag
behave like all other Go flags and take just a single argument.
The old syntax will continue to be accepted (it is rewritten into the new
syntax before flag parsing). Maybe some day we will be able to retire it.
Even if we never retire the old syntax, having the new syntax at least
makes the rewriting much less of a kludge.
Change-Id: I91e8df94f4c22b2186e81d7f1016b8767d777eac
Reviewed-on: https://go-review.googlesource.com/10310
Reviewed-by: Rob Pike <r@golang.org>
These are the Go 1.4 docs but refreshed for Go 1.5.
The most sigificant change is that all references to the Plan 9 toolchain are gone.
The tools no longer bear any meaningful resemblance.
Change-Id: I44f5cadb832a982323d7fee0b77673e55d761b35
Reviewed-on: https://go-review.googlesource.com/10298
Reviewed-by: Rob Pike <r@golang.org>
Non-ELF binary formats are much less flexible and typically do not
have a good place to store the build ID.
We store it as raw bytes at the beginning of the text segment.
The only system I know of that will be upset about this is NaCl,
and NaCl is an ELF system and does not use this.
For #11048.
Change-Id: Iaa7ace703c4cf36392e752eea9b55e2ce49e9826
Reviewed-on: https://go-review.googlesource.com/10708
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Other binary formats to follow.
Using our own note instead of the GNU build ID note because
we are not the GNU project, and I can't guarantee that the semantics
of our note and the semantics of the GNU note will match forever.
(Also they don't match today.)
For #11048.
Change-Id: Iec7e5a2e49d52b6d3a51b0aface2de7c77a45491
Reviewed-on: https://go-review.googlesource.com/10706
Reviewed-by: Ian Lance Taylor <iant@golang.org>
stkcheck is flow-insensitive: It processes calls in PC order.
Since morestack was always the first call in a function,
it was a safe, conservative approximation to simply adjust stack
space as we went, recognizing morestack when it showed up.
Subsequent CLS will rearrange the function prologue;
morestack may no longer be the first call in a function.
Introducing flow-sensitivity to stkcheck would allow this,
and possibly allow a smaller stackguard.
It is also a high risk change and possibly expensive.
Instead, assume that all calls to morestack occur as
part of the function prologue, no matter where they
are located in the program text.
Updates #10587.
Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f
Reviewed-on: https://go-review.googlesource.com/10496
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We already read the address of a gcmask/gcprog out of the type data, but I
didn't know how many bytes to read. But it turns out that it's easy to
calculate, so change to do that. This means that we no longer depend on the
local symbols being present, allowing me to strip the shared libraries for
distribution and make them a lot smaller.
As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now.
Change-Id: I379d359e28d63afae6753efd23efdf1fbb716992
Reviewed-on: https://go-review.googlesource.com/10377
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The motivation for this is the innocuous looking test case that is added. This
creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem
comes from the fact that a function from libdep.so gets inlined all the way
into exe. This (unsurprisingly) means that the object file for exe references
symbols from libdep.so, which means that -ldep needs to be passed when linking
exe and it isn't. The fix is simply to pass it -- there is no harm in passing
it when it's not needed.
The thing is, it's not clear at all in the current code to see how the linker
can know that libdep2 is linked against libdep. It could look through the
DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it
feels better to be explicit. So this adds another SHT_NOTE section that lists
the shared libraries a shared library was linked against, and makes sure the
complete set of depended upon shared libraries is passed to the external
linker.
Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2
Reviewed-on: https://go-review.googlesource.com/10376
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
