[Linaro-dev] Discussion on new ARM hard-float port on debian-arm@

[Dave Martin]

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