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

[Loïc Minier]

On Mon, Jul 12, 2010, Mark Mitchell wrote:
> 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.

 Yes; in fact, the lpia port in Ubuntu was  painful for some of these
 reasons:
 - maintaining the port, buildds, update source packages for lpia, ...
 - validating twice
 - no ISV package (e.g. skype_i386.deb)

 ...but the biggest pain was its absence in Debian!  This is an
 important point: what's not in Debian is pain to maintain, and a port
 even more so because it's all over the place.

 People come to me and ask about building hard-float images; they
 believe it will be faster, and I can certainly imagine it will be, but
 it's not clear how fast; nevertheless they want the best.  I can't
 suggest them to use the "armel" port for that, because it would mean
 the system would appear to be compatible with packages built for a
 different ABI -- the right way to do a .deb hard-float image is to use
 a different dpkg architecture name.  But they can't do that because a
 new port is too much effort for their own project.  Now I could also
 tell them that they could extend the toolchain and some libraries to
 achieve this, but again it's not something they can do right now nor
 undertake by themselves.

 hard-float Debian port; pros:
 + motivated Debian people working on it now
 + toolchain can already do it
 + best possible binaries for hard-float systems

 cons:
 - fragmentation
 - cost of maintaining the port


 extension to the toolchain and some libs to support hard-float flavors
 of some functions; pros:
 + rips out biggest benefits of hard-float
 + single binary works on all systems; no fragmentation

 cons:
 - not there yet and can't be done by the Debian people who would work
   on a new port
 - manual changes to libraries, only some libraries benefit
 ? more complex toolhain

 The arguments in terms of disk and memory usage are pretty much the
 same I made  :-)  except I think the hard-float case is in a better
 place: its binaries will be just a bit smaller, and I don't see an
 issue with a vendor including a soft-float libc if that's what the
 vendor wants to do for maximum compatibility.  This situation is
 similar to 64-bits system including a set of 32-bits libraries to run
 proprietary software; of course the 64-bits aren't usually challenged
 for disk space.

 Perhaps one way to kill the size/memory discussion would be to have a
 mechanism to strip down the special double-ABI binaries, e.g. libm.  Do
 you think this would be possible?

 Also, why do we only consider libm / manual optimizations with source
 attributes?  Wouldn't it be possible to apply this mixed-float approach
 to random C libraries automatically?  I'd very much like this to be the
 case, because that would make it possible to use a "do mixed-float
 flavors" flag in gcc across a whole distro and worry about striping
 down the binaries later, either to tailor for hard-float or to tailor
 for soft-float; it would cover all libraries rather than manually
 optimized ones like libm and would make supporting these two flavors
 easier.


 What I perceive as high risks:
 - doing a lot of work such as a new port or large toolchain
   developments, and then discovering they are not worth the gain
   (anymore) in some months; perhaps because the VFP unit has been
   improved substantially
 - doing the toolchain changes, but still seeing a measurable difference
   across hard-float and mixed-float worlds, because a bunch of small
   libraries use floats here and there

 What I perceive as medium risk:
 - spending time doing these toolchain changes instead of more useful
   ones

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

 I am, but I don't like proxying arguments and I hate have both Linaro
 and Debian hats without real toolchain contributions to backup
 toolchain positions.  I have background to comment on the pain of new
 ports for sure, but not in favor of the toolchain changes; and I would
 be perceived as biased if I were to recommend to Debian not to do
 anything right now and to wait for Linaro's new toolchain features in 6
 months...

-- 
Loïc Minier