[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

[Jon Masters]

Folks,

I've taken the liberty of inviting myself to the party :) I'm also on
IRC on Freenode, and have been following RPM development for some time
in a lurking capacity. A number of you know me from the office, but
greetings to everyone else!

We're currently engaged in bootstrapping support for "hardfp"[0] in the
Fedora Linux distribution (specifically, in release 15 thereof) for use
by systems featuring an ARM version 7 A (Application) processor or later
ARM. This is a new ABI as far as Linux is concerned, and it is parallel
installable with the older "EABI" or (loosely) "softfp" that has been
supported up until this point (for example in our ARM version 5 port, as
released in Fedora 13).

Currently, we have a hacked up RPM binary that introduces e.g.:

* armv7hl
* armv7nhl (MeeGo disagrees on this and calls it "hnl" btw)
* armv7thl [1]

Dennis has some code (he can forward) that is carried in F15 currently,
and which Panu has previously taken a look at. It uses the typical
parsing of /proc as an approach, though we agree that the "correct" way
to do that would be through AT_HWCAPS, as in here:

https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures

(last raised on rpm-maint@ in 2008 as it turns out :) )

All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're
going to be running in hardfp. We can keep that notion around in the
very short term, but we need a longer term solution. And although we
don't necessarily plan actual parallel installs of different ABIs, it is
not technically the case that all ARMv7 systems are going to be running
the hardfp port. We may e.g. install an ARMv5 port therein.

Add to this the fact that we now have X32 (a new x86 32-bit ABI) in the
Intel world, and it's clear that RPM needs a generic way to handle
multiple possible ABIs within the same architecture. I personally favor
the "multiarch" approach being taken by Debian, but I don't really want
to espouse one particular approach here. What I do want to do is to kick
off a discussion thread in which you RPM folks can decide how you want
to handle multiple ABIs in both the ARM and non-ARM worlds that myself,
Dennis, and others occupy. I'm sure Dennis, Panu, and others can point
folks at existing patches.

What I want out of this discussion is a decision around how multiple
ABIs within an architecture will be handled in general. If you're
allergic to ARM, consider that in the Intel space there is now IA32,
X32, and X64. The former is a 32-bit architecture, and the latter are
both ABIs layered upon the 64-bit architecture. ARM and Intel aren't
alone in this, there are others out there doing similarly fun things.

Thanks for your time. I'm attaching Dennis' original patch. Just so you
can see what it does, not so that you can directly consider that as the
solution that will be necessarily eventually in upstream if you can
figure out a preferred means to generically handle multiABI.

Thanks for your collective time,

Jon.

P.S. Officially I took the day off today so I might not respond if you
ping me on IRC. But email should be working :)

[0] Begin TMI. "hardfp" is really a newer ABI extension to the existing
ARM ABI. The existing ABI is sometimes referred to as "EABI", but that
term is no longer officially used by ARM. When we (the Linux community -
we've even agreed between different distributions!) refer to hardfp, we
mean the presence of a version 3 VFP unit, and conformance to section 6
of the ARM Architecture Procedure Calling Standard (AAPCS), in which an
extension to the ABI is detailed that involves the lower 16 registers of
a -d16 or -d32 (but -d16 is all we rely upon) VFPv3. Anyway. It's an ABI
that is actually standardized :)

[1] The "t" stands for "T"humb2, a compressed in size instruction set
that is also supported by ARMv7 Application processors. Using Thumb can
buy some increases in performance, but it is a different ISA, and some
of the packages involved do not yet build cleanly. Thumb(2) uses a
concept known as interworking, in which the PLT (Procedure Linkage
Table) is used to trampoline into Thumb2 code at all call points. When
we do that, we are always in ARM mode. Consequently, we arbitrarily may
switch over to Thumb2 if we care in the future, replacing one library at
a time without breaking any existing stuff. Not an ABI issue and not
really directly relevant to this thread, but some are confuzzled by the
mention of Thumb, and hence this clarification.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm-4.9.0-armhfp.patch
Type: text/x-patch
Size: 5998 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20110915/b5c226ad/attachment.bin>