Re: ARM: How does __attribute__((pcs("aapcs"))) should be used in HardFP ABI programs?

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 08/04/15 22:12, Juan Gómez wrote:
> Hi! I ended up here  because of the subject message, but it started
> some time ago here:
> http://stackoverflow.com/questions/28932005/how-does-attribute-pcsaapcs-should-be-used-in-hardfp-abi-programs
> . I'd like to run hardfp with softfp programs/libraries by makeing
> some kind of wrapper/adapter. So one approach to do it could be
> exploiting aapcs / aapcs-vfp attributes, but I'm not really sure if
> this attributes work like I think they would. All the details are in
> the stackoverflow question, but I'll paste them here as well:
> 
> I have a HardFP ABI (very) simple test program. It links with other
> HardFP binaries without any problems. Now I wanted to use a function
> from a Softfp ABI library in my code, so I changed the header file
> (.h) from this library to add the attibute: __
> attribute__((pcs("aapcs"))) on every function which uses double args
> (like: void doSomething(double arg, double arg2)), so I'm telling the
> toolchain that this library uses softfp ABI. The problem is that the
> toolchain (arm-linux-androideabi-4.9) is yelling me that:
> 
> /media/data_disk/b2g/work/hardfp/arm-linux-androideabi-4.9/bin/../lib/gcc/arm-linux-androideabi/4.9.x-google/../../../../arm-linux-androideabi/bin/ld:
> error: /tmp/cc6SmP3D.o uses VFP register arguments, output does not
> /media/data_disk/b2g/work/hardfp/arm-linux-androideabi-4.9/bin/../lib/gcc/arm-linux-androideabi/4.9.x-google/../../../../arm-linux-androideabi/bin/ld:
> error: /home/jgomez/b2g/build.flatfish.hardfp/out/target/product/flatfish/obj/lib/libc.so
> uses VFP register arguments, output does not
> /media/data_disk/b2g/work/hardfp/arm-linux-androideabi-4.9/bin/../lib/gcc/arm-linux-androideabi/4.9.x-google/../../../../arm-linux-androideabi/bin/ld:
> error: /home/jgomez/b2g/build.flatfish.hardfp/out/target/product/flatfish/obj/lib/libstdc++.so
> uses VFP register arguments, output does not
> /media/data_disk/b2g/work/hardfp/arm-linux-androideabi-4.9/bin/../lib/gcc/arm-linux-androideabi/4.9.x-google/../../../../arm-linux-androideabi/bin/ld:
> error: /home/jgomez/b2g/build.flatfish.hardfp/out/target/product/flatfish/obj/lib/libm.so
> uses VFP register arguments, output does not
> 
> (Of course, libc, libstdc++, and libm are hardfp too).
> 
> It doesn't compile.
> 
> So my question is, How does __attribute__((pcs("aapcs"))) should be
> used to let HardFP ABI programs link with Softfp ABI binaries?
> 
> I thought that this was the purpose of such a flag. Am I wrong?
> 
> Thanks!!
> 


You're not wrong, but you are running up against limitations in the
tools.  The ABI has a mechanism for describing how objects were
compiled, but it's fairly simple and it can't reason about how a mixture
of objects would interact -- it's designed to catch the normal case
where people accidentally try to link incompatible objects together.

The pcs("aapcs") attribute was mainly intended to support GCC's internal
uses, where the floating-point support functions use the soft-float ABI
- but things are carefully controlled there, so that although the code
is soft-float, it's still built with attributes describing it as
hard-float (!!) when its intended to go into a hard-float build.

If you're prepared to play fast-and-loose, you could try using objcopy
to strip the build attributes off some of the object files entirely; but
it's an all-or-nothing approach (you can't strip of just the attributes
you don't want).  If the linker encounters an object file with no
attributes at all, it will just trust that you're doing something sane.
 The section you'd want to strip out is called ".ARM.attributes".

There might be other tricks you could play, by post-processing the
assembly files generated by GCC to remove the attributes that cause the
problems, but I'm afraid I couldn't describe the details off the top of
my head, so you'd have to experiment.  The ABI documents you'd need to
read are here
(http://infocenter.arm.com/help/topic/com.arm.doc.set.swdev/index.html)
and in particular you need to read the addendum document that describes
build attributes.

Hope that helps somewhat.

R.
R.