Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: support PIE when using the external linker #6940

Closed
gopherbot opened this issue Dec 12, 2013 · 17 comments

Comments

Projects
None yet
5 participants
@gopherbot
Copy link

commented Dec 12, 2013

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2013

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2013

Comment 2:

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

This comment has been minimized.

Copy link
Author

commented Dec 13, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2013

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

This comment has been minimized.

Copy link
Author

commented Dec 14, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2013

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

This comment has been minimized.

Copy link
Author

commented Jan 5, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 2, 2014

Comment 8 by SystmKor:

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

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 2, 2014

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

This comment has been minimized.

Copy link
Member

commented Nov 3, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 3, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 3, 2014

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.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title cmd/ld: support PIE when using the external linker cmd/link: support PIE when using the external linker Jun 8, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2015

Given we can build actual shared libraries out of Go code now, building pie executables shouldn't be that hard. I'm not sure what changes are required though.

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2016

-buildmode=pie is a thing now, so it would be possible to use that. OTOH, I don't actually understand what breaks when it is not used and the system linker assumes it by default...

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2016

I've just run into something similar, but I think this specific bug is closed. We even test cgo with -linkmode=external -extldflags "-pie" now.

@mwhudson mwhudson closed this Apr 26, 2016

mbland added a commit to mbland/gvm that referenced this issue Dec 11, 2016

Add apply_patches function and initial patches
These patches are for two issues:

* Enabling Go to build on Alpine by disabling PIC per:
  golang/go#6940
  https://github.com/docker-library/golang/blob/master/1.7/alpine/no-pic.patch
* Fixing Go 1.4 bug appearing on macOS 10.12.1 per:
  golang/go#16352 (comment)

mbland added a commit to mbland/gvm that referenced this issue Dec 11, 2016

Add apply_patches function and initial patches
These patches are for two issues:

* Enabling Go to build on Alpine by disabling PIC per:
  golang/go#6940
  https://github.com/docker-library/golang/blob/master/1.7/alpine/no-pic.patch
* Fixing Go 1.4 bug appearing on macOS 10.12.1 per:
  golang/go#16352 (comment)

@golang golang locked and limited conversation to collaborators Apr 26, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.