[fedora-arm] Re: [PATCH, RFC] arm: add support for VFP architectures

[Mark Hatle]

Lennert Buytenhek wrote:
> On Thu, Jan 03, 2008 at 11:01:46AM -0600, Mark Hatle wrote:
> 
>>> (please CC on replies, I'm not on rpm-maint@)
>>>
>>> The attached patch adds a 'v' near the end of the machine name if
>>> the (ARM) system we're running on supports VFP.  This allows building
>>> and using VFP-optimised RPM packages for ARM systems that have a VFP
>>> floating point unit.  
>>>
>>> So e.g. glibc-2.7-2.armv5tel.rpm is the regular (softfloat) glibc that
>>> we have now, and glibc-2.7-2.armv5tevl.rpm would then be a glibc built
>>> to use VFP instructions, installable only on systems that have HWCAP_VFP.
>> As far as I was aware there wasn't a standard naming convention for VFP
>> in the arm cpu name.
> 
> Yeah, that's correct.  It's not one of the feature letters.
> 
> 
>> So I'm a bit concerned that adding "...evl" (or ...evb) is going to
>> be confusing in the name.
>>
>> What we have done is called it armv5el_vfp.
> 
> I've considered that, but that breaks configure scripts that match
> against arm*b-* to determine whether the target is big-endian or not.
> 
> Using the 'v' is a bit of a hack, but I can't come up with anything
> better.

We haven't found any configure scripts that change when VFP is enabled 
or not.  So as long as the compiler is doing the right thing and the RPM 
macros are setup to properly list the gnu style arch, I think this is a 
better answer.  It's a lot more obvious as to what is being attempted 
then embedding the 'v'.

> 
>>> (I would really like not to have to parse /proc/cpuinfo, but I don't
>>> see how to get at _dl_hwcap or AT_HWCAP -- as far as I see, ld.so uses
>>> this info to determine its library search path but doesn't export the
>>> info.)
>> The HWCAP stuff in in the aux vector of course.  I found a reference to
>> reading it from /proc/self/auxv, but I swear there is another way to
>> read this information w/o having to open any files.
> 
> I had a quick look at glibc, but I don't see any place where it makes
> the info available.  If you have this working, I'd be interested.

glibc does not export it directly.  According to the glibc maintainers 
the only proper way to do this is either w/ an additional argument to 
main or reading the contents of /proc/self/auxv.  The main arg way is 
easier of course, but requires a more structural change.

>>> Ideas?
>> An alternative suggestion.  Instead of changing the name or the arch,
>> would it make sense to use HWCAP settings as a run-time dependency.
>> This would allow in-kernel VFP emulation (if there ever was a such a
>> thing implemented) to set the capability and run/install the code as
>> appropriate.
> 
> I don't understand that last sentence -- how does the approach I
> proposed not allow having an in-kernel VFP emulator set HWCAP_VFP?

RPM could set an internal dependency (provide) when VFP is available. 
The rpm packages that use VFP, could have an associated dependency 
(require) for that item.  It may not be as obvious because it's not in 
the arch name.. but really all ARCH is, is a form of dependencies.

--Mark