The subject explains the issue; I have also opened an upstream bug for this.
Running gdb on a "hello world" Go program works: % gdb -iex 'add-auto-load-safe-path /usr/lib64/go/src/runtime' hello GNU gdb (Gentoo 7.11 vanilla) 7.11 ... (gdb) start Temporary breakpoint 1 at 0x401000: file /var/tmp/portage/dev-lang/go-1.6.1/work/hello.go, line 5. Starting program: /var/tmp/portage/dev-lang/go-1.6.1/work/hello [New LWP 26259] [New LWP 26260] [New LWP 26261] Thread 1 "hello" hit Temporary breakpoint 1, main.main () at /var/tmp/portage/dev-lang/go-1.6.1/work/hello.go:5 5 func main() { Doing the same thing under sandbox, we don't hit the breakpoint: (gdb) start Temporary breakpoint 1 at 0x401000: file /var/tmp/portage/dev-lang/go-1.6.1/work/hello.go, line 5. Starting program: /var/tmp/portage/dev-lang/go-1.6.1/work/hello Hello world During startup program exited normally. "hello" is (according to ldd) statically linked. If Go produces a dynamically linked executable (I don't know the correct way of doing that, but "go build -buildmode=pie hello.go" seemed to work) gdb works better: (gdb) start Temporary breakpoint 1 at 0xc82f0: file /var/tmp/portage/dev-lang/go-1.6.1/work/hello.go, line 5. Starting program: /var/tmp/portage/dev-lang/go-1.6.1/work/hello [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff7403700 (LWP 27688)] [New Thread 0x7ffff6c02700 (LWP 27689)] [New Thread 0x7ffff6401700 (LWP 27690)] [New Thread 0x7ffff5c00700 (LWP 27691)] Thread 1 "hello" hit Temporary breakpoint 1, main.main () at /var/tmp/portage/dev-lang/go-1.6.1/work/hello.go:5 5 func main() { (gdb) info goroutines * 1 running runtime.systemstack_switch * 17 syscall runtime.goexit 2 runnable runtime.forcegchelper 3 waiting runtime.gopark 4 runnable runtime.runfinq IIUC sandbox uses ptrace to catch sandbox violations by static binaries, which won't support its LD_PRELOAD approach. I suspect making gdb work under those conditions is not feasible, and changing Go's testsuite to use a dynamically linked test binary here (assuming the test fails for the same reason) is more sensible.
I have applied a patch based on the one referred to in the upstream bug to fix this issue in both 1.6.1 and 1.6.2. I did not revbump because this only affects systems with test in FEATURES. features=test this package wouldn't install.
And that fixes it? How puzzling! The patch reads as if it fixes a different problem than the one I was seeing. I'll have to try to work out why that helps once I'm back at my devbox...
