[Linaro-dev] Discussion on new ARM hard-float port on debian-arm@
dave.martin at linaro.org
Tue Jul 13 12:05:55 BST 2010
On Tue, Jul 13, 2010 at 11:50 AM, Richard Earnshaw <rearnsha at arm.com> wrote:
> On Mon, 2010-07-12 at 10:28 +0100, Dave Martin wrote:
>> 2. 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
> 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
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
More information about the Linaro-dev