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: incorrect header flags for arm hard-float/soft-float #7094

Closed
gopherbot opened this issue Jan 10, 2014 · 9 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

commented Jan 10, 2014

by james.page@canonical.com:

What steps will reproduce the problem?
build golang package on Ubuntu development release; shared library dependency generation
fails due to incorrect identification of binaries as soft-float rather than hard-float
due to incorrect headers.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g (I think).

Which operating system are you using?
Ubuntu development release

Which version are you using?  (run 'go version')
go1.2

Please provide any additional information below.
Patch to be provided.
@gopherbot

This comment has been minimized.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Jan 10, 2014

Comment 2 by james.page@canonical.com:

Patch to fixup headers (from Adam Conrad)

Attachments:

  1. 016-armhf-elf-header.patch (835 bytes)
@minux

This comment has been minimized.

Copy link
Member

commented Jan 11, 2014

Comment 3:

the issue is easy, but the fix is not.
We can't rely on host configuration to set the binary headers ABI flags (as the patch in
#2 did).
How can we get to know which ABI flag to use for each binary? We probably should discover
that by looking at intermediate cgo outputs.
another easy solution will be to disable internal linker entirely for cgo on Linux/ARM.

Labels changed: added release-go1.3, repo-main.

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 9, 2014

Comment 4:

Labels changed: added release-none, removed release-go1.3.

@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: incorrect header flags for arm hard-float/soft-float cmd/link: incorrect header flags for arm hard-float/soft-float Jun 8, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2015

Looking at the cgo intermediate outputs sounds sensible but doesn't actually work in practice because gcc does not set the correct flags. Looking for eabihf in the output of $CC -dumpmachine is the cleanest "correct" fix I can think of.

For distro package builds, I think always using the external linker for cgo would be fine (although for Ubuntu specifically we could just set the flag to armhf unconditionally as we only build for that these days...)

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2015

Can someone assign this to me please?

@minux

This comment has been minimized.

Copy link
Member

commented Sep 12, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2015

You mean a system which has a binary go install but no C compiler? Makes sense -- maybe the value of $CC -dumpmachine should be recorded by cgo rather than inspected by the linker?

mwhudson added a commit to mwhudson/go that referenced this issue Sep 23, 2015

cmd/cgo, cmd/compile, cmd/link: set the ELF headers of ARM executable…
…s that use cgo correctly

Debian and Ubuntu build infrastructure on ARM systems assumes that the ELF flags
describing the float abi an executable uses matches those of the system libraries
it links against. Go's linker currently always produces executables declaring
that they use the soft-float ABI, but really the decision over what ABI to use is
made by the C compiler during the invocation of cgo. So this records, the best way
I know how, the abi that compiler uses during the cgo run and records it in a way
that gets through to the linker, which can then set the flags appropriately.

Fixes golang#7094

Change-Id: If0d9fc5219549dcc7910c0651017462375e01eb4
@gopherbot

This comment has been minimized.

Copy link
Author

commented Sep 23, 2015

CL https://golang.org/cl/14860 mentions this issue.

@gopherbot gopherbot closed this in 3e6334e Oct 6, 2015

mwhudson added a commit to mwhudson/go that referenced this issue Jan 4, 2016

cmd/link: set the ELF headers of ARM executables that use cgo correctly
It is generally expected that the ELF flags of a dynamically linked executable
and the libraries it links against match. Go's linker currently always produces
executables with flags that do not declare a float abi (hard, soft) at all, but
when cgo is involved it is unlikely that this matches the system libraries
being linked against -- really the decision about ABI is made by the C compiler
during the invocation of cgo.

This change is basically a port of the code from binutils that parses the
".ARM.attributes" section to check for the tag that declares that the code is
built for the hard-float ABI.

Fixes golang#7094

Change-Id: I737c8f3b5ed4af545cfc3e86722d03eb83083402

mwhudson added a commit to mwhudson/go that referenced this issue Jan 4, 2016

cmd/cgo, cmd/compile, cmd/link: set the ELF headers of ARM executable…
…s that use cgo correctly

It is generally expected that the ELF flags of a dynamically linked executable
and the libraries it links against match. Go's linker currently always produces
executables with flags that do not declare a float abi (hard, soft) at all, but
when cgo is involved it is unlikely that this matches the system libraries
being linked against -- really the decision about ABI is made by the C compiler
during the invocation of cgo. So this records, the best way I know how, the abi
that compiler uses during the cgo run and records it in a way that gets through
to the linker, which can then set the flags appropriately.

Fixes golang#7094

Change-Id: If0d9fc5219549dcc7910c0651017462375e01eb4

@golang golang locked and limited conversation to collaborators Oct 9, 2016

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.