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

[ClarkGuan]

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.

   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]

/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]

/cc @crawshaw @hyangah

[davecheney]

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 https://github.com/golang/go/issues/15862#issuecomment-226645230, or mute the thread https://github.com/notifications/unsubscribe/AAAcA9Px4AiGITVzkzP9kM2aUcqWLH0lks5qMeAQgaJpZM4Ioui0 .

[ianlancetaylor]

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?

[mwhudson]

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]

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]

@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]

@ianlancetaylor OK, thx~