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.