[Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
Jeff Johnson
notifications at github.com
Thu Apr 19 09:58:21 UTC 2018
The critical values for rpm installation are the file color bits, not the ever evolving arch names.
The color values originally mapped onto the elf 32 and 64 bit designators because that is all that mattered at the time. The color value was designed as a bit mask to accomodate the insanity that a single *.a archive file might contain both 32 and 64 bit elf files.
After looking up wtf!?! the "ILP32" stands for (a designator that indicates which of integer/long/pointer are 32 bits), a 4 bit mask composed of ILP and endianness might be a better choice than elf architectures for deciding elf file colors.
Since C dictates that sizeof(long) == sizeof(pointer) afaik, only 3 bits are needed: let's call the set either PIE (or LIE ;-) with E for endianness.
Ignoring the arcane issue of a single elf file being both 32 and 64 bit -- which was actually used on ia32 may that dinosaur platform burn in hell -- then there is an almost sensible mapping of a PIE designator onto the existing color values.
Existing conventions for file colors are:
0 == uncolored, as in file doesn't have an ABI
1 == 32 bit
2 == 64 bit
4 == mips "other endian" (I.e. big endian) (and in PLD, used for x32)
8 == (unused)
The one oddball is x32 (used in PLD iirc), where the 0x4 bit which would naturally represent E (as in "other" endianness, different from usual convention) is abused to indicate a 3rd relevant elf abi that might be encountered.
Since ILP32 on arm64 is formally the same solution as X32 on x86_64 (please substitute the latest and greatest arch designators as appropriate), perhaps it's time to do the following for file colors:
1) always use 0x4 as E (I.e. "other endian", as in the non-typical ordering)
2) choose some simple algorithm based on P and I sizeof comparisons that assigns the values of the 0x1 and 0x2 bits compatible with existing practice. Ideally (in this proposal) x32 would map onto 0x3 rather than abusing 0x4.
3) reserve the 0x8 bit for an alternative abi designator, like a 128 bit architecture.
Anyways, these are idle thoughts on choosing file colors for ILP32 on arm, which also comes in an "other endian" flavor, necessitating Yet Another Bit assignment if/when the existing ad hoc scheme for choosing file colors is extended Yet Again.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#issuecomment-382679371
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180419/cccf40d2/attachment.html>
More information about the Rpm-maint
mailing list