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

[Lennert Buytenhek]

On Mon, Jan 14, 2008 at 12:44:06PM -0600, Mark Hatle wrote:

> >>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.

E.g. if you try to compile gcc for a big-endian ARM system, the build
will certainly break if you pass it armv5teb_vfp-* or armv5eb_vfp-*
or something like that.


> 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'.

That's generally how features are encoded on ARM, though.  Like how
'ARMv5, Thumb, Extended DSP instructions' is encoded as 'armv5te' and
not as 'armv5_thumb_edsp'.

Right now, the rpm arch name for ARMv5TE little-endian is is
'armv5tel', and it would be kind of weird to have the Thumb and EDSP
capabilities encoded as single letters but to have VFP encoded as
_vfp in the same arch name.


> >>>(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.

OK.


> >>>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.

The problem with that would be that RPM package file names for VFP
and non-VFP packages would be identical.