1
0
mirror of https://github.com/golang/go synced 2024-11-18 06:34:53 -07:00
Commit Graph

13 Commits

Author SHA1 Message Date
Shenghou Ma
fa563ae82e cmd/ld, cmd/6l, cmd/8l: sort exported dynamic symbols for Darwin
Also corrected cmd/8l's .dynsym handling (differentiate between exported symbols and imported symbols)

        Fixes #4029.

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6620075
2012-10-10 00:55:48 +08:00
Joel Sing
9536480edc cgo: process DWARF info even when debug data is used for value
Always process the DWARF info, even when the const value is determined
using the debug data block. This ensures that the injected enum is
removed and future loads of the same constant do not trigger
inconsistent definitions.

Add tests for issues 2470 and 4054.
Fixes #4054.

R=golang-dev, fullung, dave, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6501101
2012-09-20 13:20:33 +10:00
Alex Brainman
7f075ece42 runtime: increase stack frame during cgo call on windows/amd64
Fixes #3945.

R=golang-dev, minux.ma
CC=golang-dev, vcc.163
https://golang.org/cl/6490056
2012-09-03 12:12:51 +10:00
Shenghou Ma
e607380ff6 cmd/ld: handle a special case of scattered relocation 2/1 on Darwin/386
Fixes #1635.

R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/6496043
2012-08-29 23:42:05 +08:00
Shenghou Ma
551d8b9ff5 cmd/go: new cgo build procedure
This CL adds a step to the build procedure for cgo programs. It uses 'ld -r'
to combine all gcc compiled object file and generate a relocatable object file
for our ld. Additionally, this linking step will combine some static linking
gcc library into the relocatable object file, so that we can use libgcc,
libmingwex and libmingw32 without problem.

   Fixes #3261.
   Fixes #1741.
   Added a testcase for linking in libgcc.

TODO:
1. still need to fix the INDIRECT_SYMBOL_LOCAL problem on Darwin/386.
2. still need to enable the libgcc test on Linux/ARM, because 5l can't deal
with thumb libgcc.

Tested on Darwin/amd64, Darwin/386, FreeBSD/amd64, FreeBSD/386, Linux/amd64,
Linux/386, Linux/ARM, Windows/amd64, Windows/386

R=iant, rsc, bradfitz, coldredlemur
CC=golang-dev
https://golang.org/cl/5822049
2012-08-17 03:42:34 +08:00
Ian Lance Taylor
f7f91a0506 misc/cgo/test: only run setgid test on GNU/Linux
Fixes #3874.

R=golang-dev, nj, r, minux.ma
CC=golang-dev
https://golang.org/cl/6446060
2012-07-28 10:40:51 -07:00
Ian Lance Taylor
c49af2ccaf misc/cgo/test: add test for issue 3871: cgo setgid hang on GNU/Linux
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6445049
2012-07-26 23:21:41 -07:00
Gustavo Niemeyer
e1cfb6f3a9 cgo: fix GoBytes
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/4956051
2011-08-30 14:33:16 -03:00
Alex Brainman
72e83483a7 runtime: speed up cgo calls
Allocate Defer on stack during cgo calls, as suggested
by dvyukov. Also includes some comment corrections.

benchmark                   old,ns/op   new,ns/op
BenchmarkCgoCall                  669         330
(Intel Xeon CPU 1.80GHz * 4, Linux 386)

R=dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4910041
2011-08-18 12:17:09 -04:00
Brad Fitzpatrick
623e7de187 os: make Setenv update C environment variables
Fixes #1569

R=rsc, bradfitzwork
CC=golang-dev
https://golang.org/cl/4456045
2011-05-02 12:38:13 -07:00
Russ Cox
f985638b94 misc/cgo/test: run tests
The new gotest ignores Test functions outside *_test.go files
(the old shell script allowed them), so replace one clumsy hack
with another.

The root problem is that the package makefiles only know
how to run cgo for source files in the package proper, not
for test files.  Making it work for test files is probably more
trouble than it's worth.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4452060
2011-05-02 13:55:51 -04:00
Robert Griesemer
6684d5503a go/printer, gofmt: simplify struct formatting and respect line breaks
Also: gofmt src misc

Fixes #1627.

R=rsc
CC=golang-dev
https://golang.org/cl/4303042
2011-03-22 11:05:26 -07:00
Russ Cox
f9ca3b5d5b runtime: scheduler, cgo reorganization
* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).

Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).

The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack.  Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler.  If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless.  Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.

* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.

Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.

The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).

The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc.  Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.

Fixes #1560.

R=iant
CC=golang-dev
https://golang.org/cl/4253054
2011-03-07 10:37:42 -05:00