cmd/link: support PIE when using the external linker

[gopherbot]

by peter.volkov:

I'm building current tip of go and one test fails:

--- FAIL: TestCgoCrashHandler (1.02 seconds)
    crash_test.go:80: output:
        # command-line-arguments
        /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/go-link-ynzhxL/go.o: relocation R_X86_64_32 against `main.func·001·f' can not be used when making a shared object; recompile with -fPIC
        /var/tmp/go-link-ynzhxL/go.o: could not read symbols: Bad value
        collect2: error: ld returned 1 exit status
        /home/peter/projects/go/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful exit status 0x100
        
        
        wanted:
        main: recovered done
        new-thread: recovered done
        second-new-thread: recovered done
        main-again: recovered done
--- FAIL: TestCgoSignalDeadlock (0.75 seconds)
    crash_cgo_test.go:25: expected "OK\n", but got "# command-line-arguments\n/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/go-link-T4Mx9x/go.o: relocation R_X86_64_32 against `type.*' can not be used when making a shared object; recompile with -fPIC\n/var/tmp/go-link-T4Mx9x/go.o: could not read symbols: Bad value\ncollect2: error: ld returned 1 exit status\n/home/peter/projects/go/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful exit status 0x100\n"
--- FAIL: TestCgoTraceback (0.88 seconds)
    crash_cgo_test.go:33: expected "OK\n", but got "# command-line-arguments\n/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/go-link-WdQPCq/go.o: relocation R_X86_64_32 against `type.*' can not be used when making a shared object; recompile with -fPIC\n/var/tmp/go-link-WdQPCq/go.o: could not read symbols: Bad value\ncollect2: error: ld returned 1 exit status\n/home/peter/projects/go/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful exit status 0x100\n"
FAIL
FAIL    runtime 15.776s


go version devel +1e3f306f9d46 Thu Dec 12 06:40:16 2013 -0800 linux/amd64

[minux]

Comment 1:

do you any special setup?
I was puzzled by the fact that those tests used the external linking mode.
you can take a look at the source code embedded in pkg/runtime/crash_cgo_test.go, and
copy them out and "go run" them to see you can reproduce the problem.

Status changed to WaitingForReply.

[minux]

Comment 2:

(I can't reproduce this problem even with external linking on linux/amd64)

[gopherbot]

Comment 3 by peter.volkov:

Well, can reproduce the problem with that embedded code.
 $ go build 3.go
# command-line-arguments
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld:
/var/tmp/go-link-Nhb93l/go.o: relocation R_X86_64_32 against `type.*' can not be used
when making a shared object; recompile with -fPIC
/var/tmp/go-link-Nhb93l/go.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
/home/peter/projects/go/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful
exit status 0x100
About environment: this is hardened gentoo linux.
Portage 2.2.7 (hardened/linux/amd64, gcc-4.7.3, glibc-2.17, 3.11.7-hardened x86_64)
=================================================================
System uname:
Linux-3.11.7-hardened-x86_64-Intel-R-_Core-TM-_i7-3520M_CPU_@_2.90GHz-with-gentoo-2.2
KiB Mem:    16291304 total,   1754736 free
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash:          4.2_p45
dev-java/java-config:     2.1.12-r1
dev-lang/python:          2.7.5-r3, 3.2.5-r3, 3.3.3
dev-util/cmake:           2.8.11.2
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.10.3, 1.11.6, 1.13.4, 1.14
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.4.7, 4.5.4, 4.7.3-r1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.17
If you need I can try to create you relatively small chroot with this problem
reproduced, or point me and I'll try to do what I can. Unfortunately ATM I don't
understand this external linkage working.

Attachments:

1. 3.go (856 bytes)

[ianlancetaylor]

Comment 4:

My guess is that gcc on this system defaults to -pie.
Can you run "go build -x 3.go" and show us the output?

[gopherbot]

Comment 5 by peter.volkov:

That's true, pie is enabled by default. It's not visible in the output though becase
it's defined in spec.
 $ go build -x 3.go
WORK=/tmp/go-build510371387
mkdir -p $WORK/command-line-arguments/_obj/
cd /tmp
/home/peter/projects/go/go/pkg/tool/linux_amd64/cgo -objdir
./go-build510371387/command-line-arguments/_obj/ -- -I
./go-build510371387/command-line-arguments/_obj/ 3.go
/home/peter/projects/go/go/pkg/tool/linux_amd64/6c -F -V -w -I
./go-build510371387/command-line-arguments/_obj/ -I
/home/peter/projects/go/go/pkg/linux_amd64 -o
./go-build510371387/command-line-arguments/_obj/_cgo_defun.6 -D GOOS_linux -D
GOARCH_amd64 ./go-build510371387/command-line-arguments/_obj/_cgo_defun.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -print-libgcc-file-name
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -I
./go-build510371387/command-line-arguments/_obj/ -o
./go-build510371387/command-line-arguments/_obj/_cgo_main.o -c
./go-build510371387/command-line-arguments/_obj/_cgo_main.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -I
./go-build510371387/command-line-arguments/_obj/ -o
./go-build510371387/command-line-arguments/_obj/_cgo_export.o -c
./go-build510371387/command-line-arguments/_obj/_cgo_export.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -I
./go-build510371387/command-line-arguments/_obj/ -o
./go-build510371387/command-line-arguments/_obj/3.cgo2.o -c
./go-build510371387/command-line-arguments/_obj/3.cgo2.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -o
./go-build510371387/command-line-arguments/_obj/_cgo_.o
./go-build510371387/command-line-arguments/_obj/_cgo_main.o
./go-build510371387/command-line-arguments/_obj/_cgo_export.o
./go-build510371387/command-line-arguments/_obj/3.cgo2.o
/home/peter/projects/go/go/pkg/tool/linux_amd64/cgo -objdir
./go-build510371387/command-line-arguments/_obj/ -dynimport
./go-build510371387/command-line-arguments/_obj/_cgo_.o -dynout
./go-build510371387/command-line-arguments/_obj/_cgo_import.c
/home/peter/projects/go/go/pkg/tool/linux_amd64/6c -F -V -w -I
./go-build510371387/command-line-arguments/_obj/ -I
/home/peter/projects/go/go/pkg/linux_amd64 -o
./go-build510371387/command-line-arguments/_obj/_cgo_import.6 -D GOOS_linux -D
GOARCH_amd64 ./go-build510371387/command-line-arguments/_obj/_cgo_import.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fmessage-length=0 -o
./go-build510371387/command-line-arguments/_obj/_all.o
./go-build510371387/command-line-arguments/_obj/_cgo_export.o
./go-build510371387/command-line-arguments/_obj/3.cgo2.o -Wl,-r -nostdlib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc.a
/home/peter/projects/go/go/pkg/tool/linux_amd64/6g -o
./go-build510371387/command-line-arguments/_obj/_go_.6 -p command-line-arguments -D
_/tmp -I ./go-build510371387
./go-build510371387/command-line-arguments/_obj/_cgo_gotypes.go
./go-build510371387/command-line-arguments/_obj/3.cgo1.go
/home/peter/projects/go/go/pkg/tool/linux_amd64/pack grcP ./go-build510371387
./go-build510371387/command-line-arguments.a
./go-build510371387/command-line-arguments/_obj/_go_.6
./go-build510371387/command-line-arguments/_obj/_cgo_import.6
./go-build510371387/command-line-arguments/_obj/_cgo_defun.6
./go-build510371387/command-line-arguments/_obj/_all.o
cd .
/home/peter/projects/go/go/pkg/tool/linux_amd64/6l -o 3 -L $WORK
$WORK/command-line-arguments.a
# command-line-arguments
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld:
/var/tmp/go-link-hxLIUS/go.o: relocation R_X86_64_32 against `type.*' can not be used
when making a shared object; recompile with -fPIC
/var/tmp/go-link-hxLIUS/go.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
/home/peter/projects/go/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful
exit status 0x100

[ianlancetaylor]

Comment 6:

The Go linker does not currently support building objects that may be linked into a PIE.

Labels changed: added repo-main, release-none.

Status changed to Accepted.

[gopherbot]

Comment 7 by enigskai:

I have the same issue on a hardened Gentoo setup, where PIE/PIC are enabled by default. 
For those who are wondering, it is possible to work around this by disabling PIC when
building.
For example: go build -ldflags '-extldflags=-fno-PIC' 3.go

[gopherbot]

Comment 8 by SystmKor:

Has there been any progress with go working with all of the PaX features?

[ianlancetaylor]

Comment 9:

If you have questions about PaX in general, please ask on the mailing list
golang-nuts@googlegroups.com.
This particular issue is about generating code that can be linked into a PIE.  There has
been no progress on that.

[gopherbot]

Comment 10 by SystmKor:

I don't have questions about PaX in general. I have posted about this subject in the
mailing list https://groups.google.com/forum/#!topic/golang-nuts/Mie3Yfawksc.
I am curious about the timeline of having fully compatible PaX and go. If there is
something I can do to expedite this I would be happy to try and help.

[minux]

Comment 11:

As I said on the mailing list, PaX offers little benefit for Go.
If you system is running purely Go code, then even without PaX,
the system is still more secure than running C/C++ programs
with PaX.

[ianlancetaylor]

Comment 12:

Please let's take any discussions about PaX to the mailing list.
This issue is only about linker support for PIE, nothing else.

[gopherbot]

Comment 13 by SystmKor:

You are right about mailing list for now. I apologize. I guess I have inadvertently
derailed the comments farther than I intended. I wasn't trying to spark a discussion
about PaX but just curious about if it was going to be a thing.

[gopherbot]

Comment 14 by SystmKor:

You're right about moving this to the mailing list. I apologize. I guess I have
inadvertently derailed the comments farther than I intended. I wasn't trying to spark a
discussion about PaX but just curious about if it was going to be a thing.