On Tue, Jul 13, 2010 at 11:50 AM, Richard Earnshaw rearnsha@arm.com wrote:
On Mon, 2010-07-12 at 10:28 +0100, Dave Martin wrote:
- Use ABI tagging (high effort, involving modifications to affected
projects - permits hardvfp ABI for explicitly selected functions)
While this might sound attractive at first, I'm not sure it will fly.
Consider tagging all the functions in libm() to use hard float.
Firstly, many people 'know' that sinf()'s prototype is
float sinf (float);
and will declare it directly rather than including math.h. That's going to quietly break. Autoconf-like tools are notorious for making assumptions like this.
Possibly dumb questions:
Why would anyone (including autoconf) do this instead of including math.h? Is this for working around "broken" headers etc.? Do you know how common this is?
Secondly, if I understand what you're suggesting, I think this just makes the world more fragmented rather than less. A library that exports
float __attribute__((pcs("aapcs-vfp"))) sinf(float)
can't be replaced by a library that exports
float __attribute__((pcs("aapcs"))) sinf(float)
because the caller must know which PCS convention is used at compile time.
Indeed - see my post of 0925 UTC. This falls under (b), which looks challenging to manage, though I didn't discuss the knock-on issues with headers and function prototypes there.
However, just tagging internal functions sounds like it could bring some benefits and is more feasible (a) - can you see any problems with that?
Cheers ---Dave