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. _______________________________________________ fedora-arm mailing list fedora-arm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-arm
