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

[Mark Mitchell]

Loïc Minier wrote:

>  It's an appealing case which you make in favor of simplicity and
>  universality, but I think this only covers half of our goals.  We
>  certainly aim at standardizing the platform, but we're also building
>  higher-level tools to base on, extend, and derive that base platform.

Sure -- but building a completely parallel distribution with a
hard-float ABI is a big cost.  It's going to cause anyone building an
application binary or library to have to build it twice, validate it
twice, etc.  In the worst case, distributors will end up deciding they
need to put both hard- and soft-float versions of libraries on their
systems, so that they can run binaries built for both versions of the
ABI, with attendant costs in terms of paging, flash usage, etc.

Before we decide that's necessary, someone should have some very good
evidence that this is really useful.  Right now, as far as I know, we don't.

> So if you think it's not a wise move to
>  invest their time into this new port, it would be good to speak
>  directly to this group bringing your arguments forward.

I don't know who the right people in Debian are; I'd rather suspect
you're a lot more connected than I. :-)

>  There's the question of the timeline too: Debian folks are excited
>  about doing (3) now, and it's within reach.  

It's within reach, sure -- but it has big long-term costs.  It's cheap
to do because there's a button to press to build a new variant of all
the packages.  But, then you have two distributions to support
forevermore, and a fragmentation cost for the entire ARM Linux community.

>  How long will it take to get the toolchain able to do (2)?

It would take months, but not years.  It's going to take a few
person-weeks to implement the source attribute.  GLIBC is going to need
to add new versions of libm functions that can be called with the
hard-float ABI, while preserving the old soft-float versions using
symbol versioning.  GDB may need some work to handle the attribute.  So,
there's non-trivial work.

But, when you're done, you actually have the solution that you really
want -- critical high-performance math functions can be called more
efficiently, and nothing else is impacted.

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713