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.

Sign up for GitHub

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

Jump to bottom

cmd/link: GOARM=7 output has no ARM attribute section, confusing readelf #15862

Open
ClarkGuan opened this issue May 27, 2016 · 8 comments
Open

cmd/link: GOARM=7 output has no ARM attribute section, confusing readelf #15862

ClarkGuan opened this issue May 27, 2016 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unplanned

Comments

@ClarkGuan
Copy link

ClarkGuan commented May 27, 2016 •
edited
Loading

Please answer these questions before submitting your issue. Thanks!
#1. What version of Go are you using (go version)?

Go 1.6
#2. What operating system and processor architecture are you using (go env)?

GOOS=android
GOARCH=arm
CC=$GOMOBILE/android-ndk-r10e/arm/bin/arm-linux-androideabi-gcc
CXX=$GOMOBILE/android-ndk-r10e/arm/bin/arm-linux-androideabi-g++
CGO_ENABLED=1
GOARM=7
go build -p=4 -pkgdir=$GOMOBILE/pkg_android_arm -tags="" -v -x -i -gcflags=-shared -ldflags=-shared
-buildmode=c-shared

  1. What did you do?
    If possible, provide a recipe for reproducing the error.
    A complete runnable program is good.

    A link on play.golang.org is best.

    Any gomobile build or bind can reproduce it.
    Segmentation fault on OS X 10.5 386 for "net" test #4. What did you expect to see?

when use “arm-linux-androideabi-readelf -A xxx.so” cmd, I hope something like this

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
#5. What did you see instead?

But output like this：

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Speed

which much like a armv5te so file...
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Jun 16, 2016
@quentinmit quentinmit added this to the Go1.8 milestone Jun 16, 2016
@quentinmit quentinmit changed the title build：android/arm building doesn't output armv7a library but armv5te cmd/compile: android/arm building doesn't output armv7a library but armv5te Jun 16, 2016
@quentinmit
Copy link
Contributor

/cc @dr2chase @rakyll

It seems like we might not honor the GOARM environment variable when writing the ELF headers. Can you please take a look?

@rakyll
Copy link
Contributor

rakyll commented Jun 16, 2016

/cc @crawshaw @hyangah

@davecheney
Copy link
Contributor

I remember this coming up about a year or so ago. There is a field in the
ELF header where we can say which sub variant of ARM we support, something
like softfloat or hardfloat. At the time the GOARM value wasn't accessible
to the bit of code that was going to write it out, and at the time that
value didn't seem to have much effect so the matter was left unresolved.

/cc @mwhudson who might remember more

On Fri, Jun 17, 2016 at 9:45 AM, JBD notifications@github.com wrote:

/cc @crawshaw https://github.com/crawshaw @hyangah
https://github.com/hyangah

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#15862 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAAcA9Px4AiGITVzkzP9kM2aUcqWLH0lks5qMeAQgaJpZM4Ioui0
.

@ianlancetaylor
Copy link
Member

We set the flags in the ELF header in parseArmAttributes in cmd/link/internal/ld/ldelf.go. But this issue is not about the ELF header, it's about the ARM attributes section.

As far as I know the Go toolchain never generates an ARM attributes section. In this case we are talking about -buildmode=c-shared, so the actual shared library is being generated by the system linker. The system linker is most likely merging the ARM attributes sections of the input files, in this case from files like crt1.o.

The fix will probably be for the Go linker to generate an ARM attributes section when producing the go.o file to pass to the external linker.

@ClarkGuan Does this actually make a difference?

@ianlancetaylor ianlancetaylor changed the title cmd/compile: android/arm building doesn't output armv7a library but armv5te cmd/link: android/arm building doesn't output armv7a library but armv5te Jun 17, 2016
@mwhudson
Copy link
Contributor

I drafted a long-ish comment, but basically I agree with Ian: does this matter? If so, we should generate an .ARM.attributes section when externally linking. We can probably just cook up an appropriate section for each GOARM value as a binary blob in the linker and just dump it into the .o file.

@ClarkGuan
Copy link
Author

Hello @ianlancetaylor , first please forgive my poor English...
I know little about ELF or .ARM.attributes. Just one problem in my Android dev job leads me to care about using which ARM Architecture to build the shared library. I think it's an issue just because using "GOARM=7" but readelf cmd says NOT. So if the instructions are truly ARMv7 style, I don't care the .ARM.attributes exists or not in the ELF file.

@ianlancetaylor
Copy link
Member

@ClarkGuan I understand that readelf says one thing and GOARM says something else. I think you are saying that it only matters because of readelf, and otherwise does not matter. That sounds like a problem that is not very important. This issue open and marked as needing a fix. However, somebody will have to write that fix. If it only matters for readelf, then I do not plan to work on it myself. I hope that somebody else will.

@ClarkGuan
Copy link
Author

@ianlancetaylor OK, thx~

@rsc rsc modified the milestones: Go1.8Maybe, Go1.8 Oct 25, 2016
@rsc rsc changed the title cmd/link: android/arm building doesn't output armv7a library but armv5te cmd/link: GOARM=7 output has no ARM attribute section, confusing readelf Oct 25, 2016
@rsc rsc modified the milestones: Go1.9, Go1.8Maybe Nov 2, 2016
@bradfitz bradfitz modified the milestones: Go1.10, Go1.9 Jun 7, 2017
@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017
@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018
@cherrymui cherrymui mentioned this issue Jun 2, 2020
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
9 participants
@bradfitz @davecheney @rsc @rakyll @quentinmit @mwhudson @ianlancetaylor @ClarkGuan @gopherbot