[Rpm-maint] Re: [PATCH,RFC] arm: add support for VFP architectures
buytenh at wantstofly.org
Mon Jan 14 19:59:05 UTC 2008
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
> 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
> >>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.
> >>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
> >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.
More information about the Rpm-maint