[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
pmatilai at laiskiainen.org
Fri Nov 4 08:58:49 UTC 2011
On 11/03/2011 09:34 PM, Jon Masters wrote:
> Panu Matilainen<pmatilai at laiskiainen.org> wrote:
>> On 10/21/2011 10:20 PM, Dennis Gilmore wrote:
>>> long term maybe we can do something better. right now im looking for
>>> way to enable yum to detect the arches correctly without it resorting
>>> to things like running readelf to determine the abi of the running
>>> system. since its noarch we cant just patch things in conditionally.
>> BTW I was under the impression the ABI information for hard vs softfp
>> simply DOES NOT EXIST in the ELF headers (or anywhere else for that
>> matter). If
>> http://wiki.debian.org/ArmHardFloatPort/VfpComparison#ld.so_hwcaps is
>> wrong (or I'm misreading it) and you know of a way to detect it
>> afterall, do let me know.
>> - Panu -
>> Rpm-maint mailing list
>> Rpm-maint at lists.rpm.org
> It is in an optional section we do carry - see readelf -A. At an ARM conference so will discuss with Steve McIntyre of ARM (who is driving this ABI on their end).
Okay, in that case there's hope. Looking at what I hope to be a suitable
Attribute Section: aeabi
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed
...the interesting part would be Tag_ABI_VFP_args, or...?
Would that happen to be available at runtime through the auxiliary
vector (hwcap or wherever)?
At buildtime, one (easy, since this IS recorded in the ELF headers)
possibility is making elfdeps generate different looking dependencies
when the VFP flag is present, eg something like "libfoo.1.so" vs
"libfoo.1.so()(vfp)", so packages for the other ABI wont satisfy
dependencies of the other one, despite both being technically compatible
architecture-wise (on a system capable of using VFP ABI)
- Panu -
More information about the Rpm-maint