code review 11485045: cmd/ld: be specific about EABI floating point ABI

cmd/ld: be specific about EABI floating point ABI

At Canonical we have a number of post build steps that analyse the final binaries. We had a bug in our tool that got confused about the floating point ABI, which we've fixed, but at the same time, it doesn't hurt for the linker to be more specific.

Update issue 5640

Be specific about EABI floating point ABI.

[dave_cheney.net, 2013-07-19 02:18:53]

Hello rsc@golang.org, minux.ma@gmail.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[dave_cheney.net, 2013-07-19 02:20:24]

An alternative solution would be to leave ld/elf.c as is, and update
hdr.flags to a specific value based on goarm in 5l just after the call
to elfinit().

On Fri, Jul 19, 2013 at 12:18 PM,  <dave@cheney.net> wrote:
> Reviewers: rsc, minux,
>
> Message:
> Hello rsc@golang.org, minux.ma@gmail.com (cc:
> golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go
>
>
> Description:
> cmd/ld: be specific about EABI floating point ABI
>
> At Canonical we have a number of post build steps that analyse the final
> binaries. We had a bug in our tool that got confused about the floating
> point ABI, which we've fixed, but at the same time, it doesn't hurt for
> the linker to be more specific.
>
> Update issue 5640
>
> Be specific about EABI floating point ABI.
>
> Please review this at https://codereview.appspot.com/11485045/
>
> Affected files:
>   M src/cmd/ld/elf.c
>
>
> Index: src/cmd/ld/elf.c
> ===================================================================
> --- a/src/cmd/ld/elf.c
> +++ b/src/cmd/ld/elf.c
> @@ -57,7 +57,11 @@
>         case '5':
>                 // we only use EABI on linux/arm
>                 if(HEADTYPE == Hlinux)
> -                       hdr.flags = 0x5000002; // has entry point, Version5
> EABI
> +#ifdef __ARM_PCS_VFP
> +                       hdr.flags = 0x5000402; // has entry point, Version5
> EABI, hard-float ABI
> +#else
> +                       hdr.flags = 0x5000202; // has entry point, Version5
> EABI, soft-float ABI
> +#endif
>                 // fallthrough
>         default:
>                 hdr.phoff = ELF32HDRSIZE;       /* Must be be ELF32HDRSIZE:
> first PHdr must follow ELF header */
>
>

[rsc, 2013-07-19 02:38:32]

It seems wrong for the binary that 5l generates to depend on a #define on
the host system. 5l is supposed to work for generating ARM binaries on any
system and produce the same binary each time. What is the real criteria for
deciding between the two values?

Russ

[dave_cheney.net, 2013-07-19 02:41:55]

For 5l, I think it is the value of goarm. For $DAYJOB we don't build
on anything but armhf, but I will redo the patch to update the flags
based on goarm after the call to elfinit().

On Fri, Jul 19, 2013 at 12:38 PM, Russ Cox <rsc@golang.org> wrote:
> It seems wrong for the binary that 5l generates to depend on a #define on
> the host system. 5l is supposed to work for generating ARM binaries on any
> system and produce the same binary each time. What is the real criteria for
> deciding between the two values?
>
> Russ
>

[rsc, 2013-07-19 02:50:25]

Can you also dig up the exact meaning of the two bits (0x400 and 0x200)? I
am particularly worried about 0x200. If it means a specific software
floating point ABI, I am sure we don't implement it. What's there we more
or less made up.

Russ

[dave_cheney.net, 2013-07-19 02:57:00]

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf,
page 16, table 4-2

On Fri, Jul 19, 2013 at 12:50 PM, Russ Cox <rsc@golang.org> wrote:
> Can you also dig up the exact meaning of the two bits (0x400 and 0x200)? I
> am particularly worried about 0x200. If it means a specific software
> floating point ABI, I am sure we don't implement it. What's there we more or
> less made up.
>
> Russ

[minux1, 2013-07-19 08:20:28]

in a sense, both constants do not match our generated code exactly.

those constants are mainly about whether the program pass fp argument
in normal arm register or vfp register. however, we always pass arguments
on stack.

i think the annotation is only relevant for cgo programs, so we could
determine
that flag from the elf header of shared library (libc.so, specifically) we
are using.