cmd/go: freebsd/amd64 support for shared/archive build modes #14327

eatonphil · 2016-02-14T20:14:21Z

It would be nice to have Freebsd/amd64 support for the shared (and c-shared, archive and c-archive) build modes. What would it take for me (or anyone) to get this started?

ianlancetaylor · 2016-02-16T04:58:39Z

It might be as simple as changing cmd/go/build.go and cmd/dist/test.go to permit the new build modes. In any case, that is the first step. Do that and then see if any tests fail.

eatonphil · 2016-02-16T16:09:59Z

Thanks! I was able to find the necessary places in cmd/go/build.go, cmd/link/internal/ld/lib.go such that a build passed the current tests. But I am having trouble finding what needs to be changed in cmd/dist/test.go

Disregarding the lack of tests, and after the build succeeded, trying to compile with the shared buildmode resulted in a compiler error saying the "_rt0_amd64_freebsd_lib" symbol doesn't exist. I copied "_rt0_amd64_linux_lib" from runtime/rt0_linux_amd64.s into runtime/rt0_freebsd_amd64.s with the necessary dependencies and names. This is way out of my league and I recognize there's not necessarily any reason this code copied from Linux should work at all on Freebsd. However, at this point, compiling with buildmode shared succeeded, but attempting to dlopen and call the symbol produced a segfault:

(gdb) run
(no debugging symbols found)...(no debugging symbols found)...[New LWP 101284]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 802008c00 (LWP 101390/a.out)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 802008c00 (LWP 101390/a.out)]
runtime.printlock () at /home/phil/vendor/go/src/runtime/print.go:34
34              mp.locks++ // do not reschedule between printlock++ and lock(&debuglock).
Current language:  auto; currently minimal
(gdb) bt
#0  runtime.printlock () at /home/phil/vendor/go/src/runtime/print.go:34
#1  0x0000000800abc080 in pthread_getspecific () from /lib/libthr.so.3
Previous frame inner to this frame (corrupt stack?)

Perhaps this all would be clearer if the right tests are enabled.

I realize that it is hard to discuss this without the changes I made, but I am confused about the best way to share my changes because I don't want to submit a code review for broken code. Maybe link to a forked repository?

ianlancetaylor · 2016-02-16T17:46:22Z

In cmd/dist/test.go you need to change the supportedBuildMode method.

Copying _rt0_amd64_linux_lib sounds right. You'll also need to add newosproc0 and libpreinit to runtime/os1_freebsd.go if you haven't already done that. libpreinit can be copied from os1_linux.go. newosproc0 can not--it will have to be adjusted to start a new FreeBSD thread, I guess using thr_new like newosproc.

To be clear, it's not expected that you will be able to dlopen a library built with -buildmode=shared. You are expected to dlopen a library built with -buildmode=c-shared--note that extra "c-".

It's fine to send in a code review for broken code, just put "DO NOT REVIEW" in the description. See https://golang.org/wiki/CodeReview .

lattera · 2016-02-18T16:46:05Z

It'd be extremely nice if compiling as a Position-Independent Executable (PIE) was supported as well on FreeBSD. HardenedBSD has implemented ASLR for FreeBSD, but golang applications can't take full advantage of ASLR since golang applications aren't compiled as PIEs.

mwhudson · 2016-02-28T21:13:00Z

As above, it's probably just a matter of finding the bits of code that allow the flags, changing them to allow freebsd, and testing it.

lattera · 2016-02-28T21:16:46Z

I have. I tested it and things went horrible. The application compiled fine, but when I tried to run it, I got segfaults. I've since lost the logs, but I"ll redo the work (it was pretty simple) and grab fresh logs when I have time.

mwhudson · 2016-02-29T07:57:34Z

Well OK. I can try to offer hints if you can post the logs (maybe in a more specific freebsd/PIE specific issue?)

fiorix · 2016-04-05T06:21:48Z

I can help testing, need c-shared on BSD too.

wclarie · 2016-06-11T14:28:52Z

Same here: would love to see c-shared support for freebsd/amd64 in order to build pam modules. Made the changes to cmd/dist/test.go, cmd/go/build.go and runtime/rt0_freebsd_amd64.s, but writing a proper newosproc0 function for runtime/os_freebsd.go is far beyond my skillset.

lattera · 2016-12-24T23:37:18Z

@wclarie could you share your changes?

Here's what I've come up with for "enabling" -buildmode=pie for FreeBSD/HardenedBSD: http://ix.io/1Odk

But attempting to run a simple "hello world" application compiled as a PIE results in this: http://ix.io/1Odl

jakob223 · 2017-08-03T12:51:19Z

I'm trying to see what it will take to get buildmode=c-shared working on FreeBSD; I've changed a line in src/cmd/dist/test.go and a line in src/cmd/go/internal/work/build.go, and go builds and is willing to run with -buildmode=c-shared (though when I examine the built .so files, they don't have any of the symbols they're supposed to have)

Now I'm running the tests, but the ../misc/cgo/testcshared test hangs, seemingly forever. If I run it directly, I get the following output:

[FreeBSD ~/go/go/misc/cgo/testcshared]$ bash test.bash                 *[master]
# libgo
/usr/bin/ld: warning: .init_array section has zero size
# command-line-arguments
/usr/bin/ld: warning: .init_array section has zero size

and then it hangs forever. Any advice on what things I should look at, and/or I'll have to change to get this to pass?

ianlancetaylor · 2017-08-03T13:51:07Z

To avoid the linker warning you may have to modify cmd/link/internal/ld/data.go to not create the .init_array section if it would be empty.

To get more information about what is not working try bash -x test.bash to see which actual test is hanging. Then debug that test.

When you say that the shared library don't have any symbols they're supposed to have, what do you mean?

jakob223 · 2017-08-04T10:10:00Z

It looks like it's the first test that's hanging:
[FreeBSD ~/go/go/misc/cgo/testcshared]$ bash -x test.bash *[master]

+ set -e
+ '[' '!' -f src/libgo/libgo.go ']'
++ go env GOOS
+ goos=freebsd
++ go env GOARCH
+ goarch=amd64
++ go env GOROOT
+ goroot=/home/vagrant/go/go
+ '[' '!' -d /home/vagrant/go/go ']'
+ installdir=pkg/freebsd_amd64_testcshared_shared
+ '[' freebsd = darwin ']'
+ androidpath=/data/local/tmp/testcshared-69570
+ trap cleanup EXIT
+ '[' freebsd = android ']'
+ rm -rf pkg
+ suffix='-installsuffix testcshared'
+ libext=so
+ '[' freebsd = darwin ']'
++ pwd
+ GOPATH=/home/vagrant/go/go/misc/cgo/testcshared
+ go install -buildmode=c-shared -installsuffix testcshared libgo
# libgo
/usr/bin/ld: warning: .init_array section has zero size
++ pwd
+ GOPATH=/home/vagrant/go/go/misc/cgo/testcshared
+ go build -buildmode=c-shared -installsuffix testcshared -o libgo.so src/libgo/libgo.go
# command-line-arguments
/usr/bin/ld: warning: .init_array section has zero size
+ binpush libgo.so
+ bin=libgo.so
+ '[' freebsd = android ']'
+ '[' freebsd = linux ']'
+ '[' freebsd = android ']'
++ go env GOGCCFLAGS
+ GOGCCFLAGS='-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build761910522=/tmp/go-build -gno-record-gcc-switches'
+ '[' freebsd = android ']'
+ status=0
++ go env CC
+ clang -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build761910522=/tmp/go-build -gno-record-gcc-switches -I pkg/freebsd_amd64_testcshared_shared -o testp main0.c ./libgo.so
+ binpush testp
+ bin=testp
+ '[' freebsd = android ']'
++ run LD_LIBRARY_PATH=. ./testp
++ case "$goos" in
+++ env LD_LIBRARY_PATH=. ./testp

I've added debug prints to testcshared/main0.c and to testcshared/src/libgo/libgo.go and it looks like the test gets to the point of calling DidInitRun, but none of init, main, or DidInitRun get called successfully enough to print anything. Any ideas why this would happen?

[FreeBSD ~/go/go/misc/cgo/testcshared]$ nm -g libgo.so | grep nit
00000000000bfc20 T DidInitRun                                    
00000000000bff60 T _cgo_wait_runtime_init_done                   
00000000000bf9e0 T _cgoexp_221f37c860b1_DidInitRun               
000000000004f9b8 T _init                                         
                 U pthread_attr_init@@FBSD_1.0                   
00000000000bfcd0 T x_cgo_init                                    
00000000000bffe0 T x_cgo_notify_runtime_init_done

When I say it doesn't have the symbols it's supposed to have, I meant that I build a shared library with go, but when I examine it with nm, it only has the default cgo things in it, and it doesn't have any of the C libraries that I include or any of the functions I define and export in go. I checked against building the same file on darwin, and on darwin it has the extra symbols.

I got the linker warnings to go away, thanks. It seems like the init function should be in a .init_array section though, so it's concerning that that wouldn't be generated. Or am I misunderstanding?

ianlancetaylor · 2017-08-04T15:02:53Z

My first hypotheses for why the test program hangs is that the .init_array section does not contain the initializer function, or that that DT_INIT_ARRAY dynamic tag was not set correctly, or that the FreeBSD dynamic linker does not honor the DT_INIT_ARRAY tag.

I don't know what is going on with the symbol table issues you mention.

jakob223 · 2017-08-04T15:05:49Z

The .init_array section is empty - do you know where it gets constructed?

ianlancetaylor · 2017-08-04T18:35:53Z

Look for calls to addinitarrdata in cmd/link/internal/ld.

jakob223 · 2017-08-07T12:26:37Z

This seems to lead back to what @eatonphil ran into above - the .init_array is empty or absent because there are no generated symbols with the name _rt0_amd64_freebsd_lib. I've copied the implementation from linux and am working on implementing newosproc0 on FreeBSD using thr_new.

That said, I've looked at the _rt0_amd64_GOOS_lib implementations for both darwin and linux, and they're subtly different. One difference is due to moving the stack pointer a little bit downward on darwin in case of there being a frame pointer (which apparently "We don't know whether Go is adding a frame pointer here or not."). There's also a difference because newosproc0 requires another argument to be on the stack in darwin, due to thread creation using bsdhread_create. I'm using purely the linux implementation for now, but I'm not entirely sure whether the frame pointer uncertainty also applies on FreeBSD because I don't know where it comes from.

jakob223 · 2017-08-07T14:12:07Z

I am successfully compiling with the modifications, but the test is still failing. Now it's crashing instead of hanging. .init_array does get put in the shared object, and it's no longer empty, so I've removed the patch that doesn't include an empty .init_array.

[FreeBSD ~/go/go/misc/cgo/testcshared]$ bash test.bash                                                           *[freebsd-cshared]
FAIL test0 got
FAIL test1 got
FAIL test2 got
FAIL test4 got
re-running test4 in verbose mode
calling sigaction
calling dlopen
test.bash: line 170: 95544 Illegal instruction     (core dumped) ./testp4 ./libgo4.$libext verbose

Running the first test in LLDB:

[FreeBSD ~/go/go/misc/cgo/testcshared]$ lldb ./testp ./libgo.so                                                  *[freebsd-cshared]
(lldb) target create "./testp"
Current executable set to './testp' (x86_64).
(lldb) settings set -- target.run-args  "./libgo.so"
(lldb) run
Process 95824 launching
Process 95824 launched: './testp' (x86_64)
Process 95824 stopped
* thread #1: tid = 101042, 0x00000008012616da libgo.so`runtime.printlock + 42 at print.go:67, stop reason = signal SIGSEGV: invalid address (fault address: 0xe0)
    frame #0: 0x00000008012616da libgo.so`runtime.printlock + 42 at print.go:67
   64
   65  	func printlock() {
   66  		mp := getg().m
-> 67  		mp.locks++ // do not reschedule between printlock++ and lock(&debuglock).
   68  		mp.printlock++
   69  		if mp.printlock == 1 {
   70  			lock(&debuglock)
(lldb) bt
* thread #1: tid = 101042, 0x00000008012616da libgo.so`runtime.printlock + 42 at print.go:67, stop reason = signal SIGSEGV: invalid address (fault address: 0xe0)
  * frame #0: 0x00000008012616da libgo.so`runtime.printlock + 42 at print.go:67
    frame #1: 0x0000000801260d23 libgo.so`runtime.throw(s=<no summary available>) + 19 at panic.go:599
    frame #2: 0x000000080125f207 libgo.so`runtime.setsigstack(i=32) + 39 at os_freebsd.go:374
    frame #3: 0x0000000801272978 libgo.so`runtime.initsig(preinit=true) + 232 at signal_unix.go:96
    frame #4: 0x000000080125ee27 libgo.so`runtime.libpreinit + 23 at os_freebsd.go:257
    frame #5: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #6: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #7: 0x0000000801260d23 libgo.so`runtime.throw(s=<no summary available>) + 19 at panic.go:599
    frame #8: 0x000000080125f207 libgo.so`runtime.setsigstack(i=32) + 39 at os_freebsd.go:374
    frame #9: 0x0000000801272978 libgo.so`runtime.initsig(preinit=true) + 232 at signal_unix.go:96
    frame #10: 0x000000080125ee27 libgo.so`runtime.libpreinit + 23 at os_freebsd.go:257
    frame #11: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #12: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #13: 0x000000080125f207 libgo.so`runtime.setsigstack(i=32) + 39 at os_freebsd.go:374
    frame #14: 0x0000000801272978 libgo.so`runtime.initsig(preinit=true) + 232 at signal_unix.go:96
    frame #15: 0x000000080125ee27 libgo.so`runtime.libpreinit + 23 at os_freebsd.go:257
    frame #16: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #17: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #18: 0x0000000801272978 libgo.so`runtime.initsig(preinit=true) + 232 at signal_unix.go:96
    frame #19: 0x000000080125ee27 libgo.so`runtime.libpreinit + 23 at os_freebsd.go:257
    frame #20: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #21: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #22: 0x000000080125ee27 libgo.so`runtime.libpreinit + 23 at os_freebsd.go:257
    frame #23: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #24: 0x0000000801289faf libgo.so`_rt0_amd64_freebsd_lib + 79 at rt0_freebsd_amd64.s:33
    frame #25: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #26: 0x0000000800604f86 ld-elf.so.1`??? + 598
    frame #27: 0x00000008006095c2 ld-elf.so.1`??? + 1810
    frame #28: 0x0000000800606301 ld-elf.so.1`??? + 385
    frame #29: 0x0000000000400a8a testp`main + 42
    frame #30: 0x00000000004007df testp`_start + 383

I'm pretty sure that my newosproc0 implementation is wrong; in particular, I think I'm not doing the right thing for the child_tid parameter to thr_new and suspect that I'm not doing the right thing for the tls parameter either. I'm not sure how I should be allocating memory for those variables, though - I would appreciate pointers there.

I'm also not sure about whether the recursion happening in the above stack trace is supposed to happen or is an artifact of my incorrect newosproc0 implementation, but I'm not really sure what the next step is debugging-wise.

My code is currently at https://github.com/jakob223/go/tree/freebsd-cshared

tenortim · 2018-02-12T15:21:26Z

I've made some more headway on this, but we're still crashing, just further along...
Disregarding the crash for a moment, the underlying reason for the previous failure (at least building from Go source from early February 2018) is because setsigstack() in runtime/os_freebsd.go is a stub throwing an error. It's easy enough to fill out this function (similarly to Linux except the flag name is _SA_ONSTACK). Once this is done, we get further. I'm getting two threads, thread 1 (main0.c) is correctly waiting for initialization to finish. Thread 2 (our libgo.so) gets a long way through initialization, but it's blowing up inside rtld:

#0  0x0000000800612265 in memcpy () from /libexec/ld-elf.so.1
#1  0x0000000800607c29 in tls_get_addr_slow (dtvp=0x800b13fa8 <runtime.g0+8>,
    index=3, offset=0) at rtld.c:4397
#2  0x0000000800e061ba in malloc () from /lib/libc.so.7
#3  0x00000008008a96a3 in x_cgo_thread_start (arg=0x7fffdfffdee8)
    at gcc_util.c:15
#4  0x00000008008a0fed in runtime.asmcgocall ()
    at /home/timw/git/go/src/runtime/asm_amd64.s:718
#5  0x0000000800ad1101 in typerel.* () from ./libgo.so

So this is the call to malloc() in x_cgo_thread_start in copying the ThreadStart, and it's dieing in the libc malloc because that's trying to use TLS and somehow our TLS for this thread is not right.
Looking over the FreeBSD rtld/TLS code, dtvp (struct dtv point) is the second element of the tcb struct, and so somehow we're treating runtime.g0 as tcb, but it's not correct.
...
A bit more debugging. On startup fs_base points to an array of tcbs and the 3 tcbs there look sane.
Specifically:

(gdb) x/4xg 0x800626340
0x800626340:	0x0000000800626340	0x0000000800625100 // tcb1, tcb2
0x800626350:	0x0000000801806400	0x0000000000000000 // tcb3
(gdb) x/4xg 0x0000000800626340
0x800626340:	0x0000000800626340	0x0000000800625100 // tcb_self, tcb_dtv
0x800626350:	0x0000000801806400	0x0000000000000000 // tcb_thread, spare
(gdb) x/4xg 0x0000000800625100
0x800625100:	0x0000000000000003	0x0000000000000003 //generation etc.
0x800625110:	0x0000000000000000	0x0000000800626338

By the time we get to the where we crash, fs_base has been modified and the first tcb pointer is now pointing at runtime.g0 which isn't a valid thread control block.

tenortim · 2018-02-12T16:47:11Z

Lots of learning. So, of course, %fs (fs_base) is different for each thread (something I didn't immediately consider). So the "modifed" fs_base is nothing of the sort. The fs register for the initial thread is the same and the tcb values are unchanged. When the second thread is created, initially, the tcb values there are also OK, but the first one gets smashed/overwritten by runtime/asm_amd64.s:235

ok:
        // set the per-goroutine and per-mach "registers"
        get_tls(BX)
        LEAQ    runtime\xc2\xb7g0(SB), CX
        MOVQ    CX, g(BX)

So I posit that get_tls() is doing the wrong thing here (it's effectively returning &tcb[0], but there are already 3 extant tcbs so it should be returning the fourth). Maybe need to play similar tricks to the Linux and Darwin code?

tenortim · 2018-02-12T16:50:33Z

gdb evidence:

(gdb) info thread
  Id   Target Id         Frame
* 1    LWP 100358 of process 34720 0x0000000800b3b43a in _pthread_create (
    thread=0x7fffffffdaf0, attr=<optimized out>,
    start_routine=<optimized out>, arg=<optimized out>)
    at /usr/src/lib/libthr/thread/thr_create.c:184
  2    LWP 100597 of process 34720 0x0000000800611a09 in sigsetjmp ()
   from /libexec/ld-elf.so.1
(gdb) x/4xg 0x800626540
0x800626540:	0x0000000800626540	0x0000000800625140
0x800626550:	0x0000000801806800	0x0000000000000000
(gdb) x/4xg 0x0000000800625140
0x800625140:	0x0000000000000003	0x0000000000000003
0x800625150:	0x0000000000000000	0x0000000800626538
(gdb) c
Continuing.
[Switching to LWP 100597 of process 34720]

Thread 2 hit Hardware watchpoint 9: *(long*) 0x800626540

Old value = 34366186816
New value = 34371354528
runtime.rt0_go () at /home/timw/git/go/src/runtime/asm_amd64.s:236
236		LEAQ	runtime·m0(SB), AX
(gdb) x/4xg 0x800626540
0x800626540:	0x0000000800b13fa0	0x0000000800625140
0x800626550:	0x0000000801806800	0x0000000000000000
(gdb) x/4xg 0x0000000800b13fa0
0x800b13fa0 <runtime.g0>:	0x00007fffdfdfef68	0x00007fffdfffdf90
0x800b13fb0 <runtime.g0+16>:	0x00007fffdfdff2d8	0x00007fffdfdff2d8

tenortim · 2018-02-12T19:42:34Z

../misc/cgo/testcshared

PASS

Needed to emit the 2-instruction versions of the TLS access calls when building shared. Fortunately, it's identical to Linux so I just needed to add the cases. I'll be preparing a PR for the changes.
Here's the additional diff:

timw@freebsd10:~/git/go/src/cmd/internal/obj/x86 % git diff .                   diff --git a/src/cmd/internal/obj/x86/asm6.go b/src/cmd/internal/obj/x86/asm6.go
index 7b80892cf0..21f4b101c3 100644
--- a/src/cmd/internal/obj/x86/asm6.go
+++ b/src/cmd/internal/obj/x86/asm6.go
@@ -4432,7 +4432,7 @@ func (asmbuf *AsmBuf) doasm(ctxt *obj.Link, cursym *obj.LSym, p *obj.Prog) {
                                                        log.Fatalf("unknown TLS base location for %v", ctxt.Headtype)

                                                case objabi.Hlinux,
-                                                       objabi.Hnacl:
+                                                       objabi.Hnacl, objabi.Hfreebsd:
                                                        if ctxt.Flag_shared {
                                                                // Note that this is not generating the same insns as the other cases.
                                                                //     MOV TLS, dst
@@ -4504,7 +4504,7 @@ func (asmbuf *AsmBuf) doasm(ctxt *obj.Link, cursym *obj.LSym, p *obj.Prog) {
                                        default:
                                                log.Fatalf("unknown TLS base location for %v", ctxt.Headtype)

-                                       case objabi.Hlinux:
+                                       case objabi.Hlinux, objabi.Hfreebsd:
                                                if !ctxt.Flag_shared {
                                                        log.Fatalf("unknown TLS base location for linux without -shared")
                                                }
diff --git a/src/cmd/internal/obj/x86/obj6.go b/src/cmd/internal/obj/x86/obj6.go
index 7b5e4769dc..a8934e4939 100644
--- a/src/cmd/internal/obj/x86/obj6.go
+++ b/src/cmd/internal/obj/x86/obj6.go
@@ -64,7 +64,7 @@ func CanUse1InsnTLS(ctxt *obj.Link) bool {
        switch ctxt.Headtype {
        case objabi.Hplan9, objabi.Hwindows:
                return false
-       case objabi.Hlinux:
+       case objabi.Hlinux, objabi.Hfreebsd:
                return !ctxt.Flag_shared
        }

gopherbot · 2018-02-14T03:32:00Z

Change https://golang.org/cl/93875 mentions this issue: Enable c-shared/c-archive support for freebsd/amd64

gopherbot · 2018-03-07T04:49:43Z

Change https://golang.org/cl/99077 mentions this issue: runtime: change from rt_sigaction to sigaction

This normalizes the Linux code to act like other targets. The size argument to the rt_sigaction system call is pushed to a single function, sysSigaction. This is intended as a simplification step for CL 93875 for #14327. Change-Id: I594788e235f0da20e16e8a028e27ac8c883907c4 Reviewed-on: https://go-review.googlesource.com/99077 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>

ianlancetaylor changed the title ~~freebsd/amd64 support for shared/archive build modes~~ cmd/go: freebsd/amd64 support for shared/archive build modes Feb 16, 2016

ianlancetaylor added this to the Unplanned milestone Feb 16, 2016

andybons added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 7, 2018

gopherbot closed this as completed in 88129f0 Mar 21, 2018

ianlancetaylor mentioned this issue Jun 6, 2018

runtime: sigaction problem when using cgo on FreeBSD #25745

Closed

DamjanJovanovic mentioned this issue Jul 13, 2018

cmd/go: support -buildmode=c-shared on freebsd/amd64 #22078

Closed

golang locked and limited conversation to collaborators Mar 21, 2019

gopherbot added the FrozenDueToAge label Mar 21, 2019

bcmills mentioned this issue Aug 26, 2019

cmd/go: support -buildmode=c-archive on android/arm64 #33806

Open

bcmills removed the FrozenDueToAge label Aug 26, 2019

golang unlocked this conversation Aug 26, 2019

golang locked and limited conversation to collaborators Aug 25, 2020

gopherbot added the FrozenDueToAge label Aug 25, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: freebsd/amd64 support for shared/archive build modes #14327

cmd/go: freebsd/amd64 support for shared/archive build modes #14327

eatonphil commented Feb 14, 2016

ianlancetaylor commented Feb 16, 2016

eatonphil commented Feb 16, 2016

ianlancetaylor commented Feb 16, 2016

lattera commented Feb 18, 2016

mwhudson commented Feb 28, 2016

lattera commented Feb 28, 2016

mwhudson commented Feb 29, 2016

fiorix commented Apr 5, 2016

wclarie commented Jun 11, 2016

lattera commented Dec 24, 2016

jakob223 commented Aug 3, 2017

ianlancetaylor commented Aug 3, 2017

jakob223 commented Aug 4, 2017

ianlancetaylor commented Aug 4, 2017

jakob223 commented Aug 4, 2017

ianlancetaylor commented Aug 4, 2017

jakob223 commented Aug 7, 2017

jakob223 commented Aug 7, 2017 •

edited

tenortim commented Feb 12, 2018

tenortim commented Feb 12, 2018 •

edited

tenortim commented Feb 12, 2018

tenortim commented Feb 12, 2018

gopherbot commented Feb 14, 2018

gopherbot commented Mar 7, 2018

cmd/go: freebsd/amd64 support for shared/archive build modes #14327

cmd/go: freebsd/amd64 support for shared/archive build modes #14327

Comments

eatonphil commented Feb 14, 2016

ianlancetaylor commented Feb 16, 2016

eatonphil commented Feb 16, 2016

ianlancetaylor commented Feb 16, 2016

lattera commented Feb 18, 2016

mwhudson commented Feb 28, 2016

lattera commented Feb 28, 2016

mwhudson commented Feb 29, 2016

fiorix commented Apr 5, 2016

wclarie commented Jun 11, 2016

lattera commented Dec 24, 2016

jakob223 commented Aug 3, 2017

ianlancetaylor commented Aug 3, 2017

jakob223 commented Aug 4, 2017

ianlancetaylor commented Aug 4, 2017

jakob223 commented Aug 4, 2017

ianlancetaylor commented Aug 4, 2017

jakob223 commented Aug 7, 2017

jakob223 commented Aug 7, 2017 • edited

tenortim commented Feb 12, 2018

tenortim commented Feb 12, 2018 • edited

tenortim commented Feb 12, 2018

tenortim commented Feb 12, 2018

../misc/cgo/testcshared

gopherbot commented Feb 14, 2018

gopherbot commented Mar 7, 2018

jakob223 commented Aug 7, 2017 •

edited

tenortim commented Feb 12, 2018 •

edited