Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Thu, 03 Nov 2011 14:26:58 +0200
Panu Matilainen escribió:
> On 10/27/2011 12:00 AM, Dennis Gilmore wrote:
> [...big snip...]
> >>> its not sufficient. it evaluates to armv7l on a hardware floating
> >>> point system. we would need it to be armv7hl or armv7hnl to give
> >>> yum the info it needs
> >>
> >> maybe _target_cpu could be used
> >>
> >> though it would need a dict of compatiable arches
> >>
> >> [dennis@panda02 ~]$ rpm --showrc |grep arm
> >> build arch: armv7hnl
> >> compatible build archs: armv7hnl armv7hl noarch
> >> install arch : armv7hnl
> >> compatible archs : armv7hnl armv7hl noarch
> >> optflags : -O2 -g -march=armv7-a -mfloat-abi=hard
> >> -mfpu=neon -mthumb gpg --batch --no-verbose --no-armor
> >> --passphrase-fd 3
> >> - -14: __isa_name armv7hnl
> >> - -14: _arch arm
> >> - -14: _build_arch arm
> >> - -14: _host armv7l-unknown-linux-gnueabi
> >> - -14: _host_cpu armv7l
> >> - -11: _target armv7hnl-linux
> >> - -11= _target_cpu armv7hnl
> >> - -14: arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl
> >> armv6l armv7l armv7hl armv7nhl
> >> - -11: optflags-O2 -g -march=armv7-a -mfloat-abi=hard
> >> -mfpu=neon -mthumb
> >>
> >>
> >> [root@trimslice01 ~]# rpm --showrc |grep arm
> >> build arch: armv7hl
> >> compatible build archs: armv7hl noarch
> >> install arch : armv7hl
> >> compatible archs : armv7hl noarch
> >> optflags : -O2 -g -march=armv7-a -mfloat-abi=hard
> >> -mfpu=vfpv3-d16 -mthumb gpg --batch --no-verbose --no-armor
> >> --passphrase-fd 3
> >> - -14: __isa_name armv7hl
> >> - -14: _arch arm
> >> - -14: _build_arch arm
> >> - -14: _host armv7l-unknown-linux-gnueabi
> >> - -14: _host_cpu armv7l
> >> - -11: _target armv7hl-linux
> >> - -11= _target_cpu armv7hl
> >> - -14: arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl
> >> armv6l armv7l armv7hl armv7nhl
> >> - -11: optflags-O2 -g -march=armv7-a -mfloat-abi=hard
> >> -mfpu=vfpv3-d16 -mthumb
> >>
> >>
> >> the first output is a system that has a neon simd unit and the
> >> second is without it. any software that can run on the second can
> >> also run on the first. __isa_name really should be the same on
> >> both.
> >>
> >> long term maybe we can do something better. right now im looking
> >> for a way to enable yum to detect the arches correctly without it
> >> resorting to things like running readelf to determine the abi of
> >> the running system. since its noarch we cant just patch things in
> >> conditionally.
> >>
> >> Dennis
> >
> >
> > ok since i have a ton of the oddball hardware here
> >
> > is there someway to get whats setting "compatible archs" in
> > --showrc? i ask because
> >
> > rpm --showrc |grep armv7
> > build arch: armv7hnl
> > compatible build archs: armv7hnl armv7hl noarch
> > install arch : armv7hnl
> > compatible archs : armv7hnl armv7hl noarch
> > optflags : -O2 -g -march=armv7-a -mfloat-abi=hard
> > -mfpu=neon -mthumb -14: __isa_namearmv7hnl
> > - -14: _hostarmv7l-unknown-linux-gnueabi
> > - -14: _host_cpuarmv7l
> > - -11: _target armv7hnl-linux
> > - -11= _target_cpu armv7hnl
> > - -14: arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl
> > armv6l armv7l armv7hl armv7nhl -11: optflags-O2 -g
> > -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
> >
> > rpm --showrc |grep sparc
> > build arch: sparc64
> > compatible build archs: sparc64v sparc64 sparcv9v sparcv9 sparcv8
> > sparc noarch install arch : sparc64v
> > compatible archs : sparc64v sparc64 sparcv9v sparcv9 sparcv8
> > sparc noarch -14: _arch sparc
> > - -14: _build_arch sparc
> > - -14: _hostsparc-unknown-linux-gnu
> > - -14: _host_cpusparc
> > - -11: _target sparc64-linux
> > - -11= _target_cpu sparc64
> > - -11: optflags %{__global_cflags} -m64 -mcpu=ultrasparc
> > - -14: sparcsparc sparcv8 sparcv9 sparcv9v sparc64 sparc64v
> >
> >
> > _host_cpu and _target_cpu on sparc doesnt give me a way to work out
> > that im on a n
Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Fri, 21 Oct 2011 14:20:13 -0500
Dennis Gilmore escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 21 Oct 2011 14:00:56 -0500
> Dennis Gilmore wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Sat, 17 Sep 2011 16:02:52 +0300
> > Panu Matilainen wrote:
> >
> > > On 09/16/2011 04:58 PM, Dennis Gilmore wrote:
> > > > On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote:
> > > >> Oh I knew this would happen... the send-button is a magic
> > > >> memory-enhancer in disguise. One (of probably many) forgotten
> > > >> bits, this
> > > >>
> > > >> time hopefully with working address for Dennish too:
> > > >>> On 09/15/2011 01:55 PM, Jon Masters wrote:
> > > >>>> All of the existing stuff assumes that if we have vfpv3 on
> > > >>>> ARMv7 we're going to be running in hardfp. We can keep that
> > > >>>> notion around in the very short term, but we need a longer
> > > >>>> term solution. And although we don't necessarily plan actual
> > > >>>> parallel installs of different ABIs, it is not technically
> > > >>>> the case that all ARMv7 systems are going to be running the
> > > >>>> hardfp port. We may e.g. install an ARMv5 port therein.
> > > >>
> > > >>From what I've heard + read about the hardfp ABI, its not
> > > >> actually possible to parallel-install with anything else
> > > >> because even the dynamic linker has no clue whether hardfp or
> > > >> some other ABI was used (see
> > > >> http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers
> > > >> to our friends over Debian side again for a nice article :)
> > > >> Which makes this a truly "unique" piece of
> > > >> work. I'd love to know why it was done that way - my layman
> > > >> sense thinks the compiler toolchain should be able to mark the
> > > >> ABI in the elf headers (heck this is what the whole hwcap
> > > >> thing is about).
> > > >> >
> > > > ___
> > > > Rpm-maint mailing list
> > > > Rpm-maint@lists.rpm.org
> > > > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > >
> > > ___
> > > Rpm-maint mailing list
> > > Rpm-maint@lists.rpm.org
> > > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > > >
> > > >> Since the ABI difference is apparently not recorded anywhere,
> > > >> there's little chance of rpm being able to automatically do the
> > > >> right thing really, and I dunno if its worth it trying to jump
> > > >> through a whole lot of hoops for what seems an unachievable
> > > >> task.
> > > >>
> > > >> One simple brute-force "solution" that should work right now is
> > > >> to just keep the softfp/hardfp "architectures" incompatible
> > > >> from rpm POV and make the assumption that hardfp ABI will be
> > > >> used if the system is capable of it. And if somebody wants to
> > > >> override this assumption, that's what /etc/rpm/platform is for
> > > >> (allow overriding rpm's hw detection).
> > > >
> > > > im not the biggest fan of this, Maybe we can hard code it
> > > > somehow at compilation time?
> > >
> > > Care to elaborate why would you want to hardcode it instead of
> > > just utilizing an existing method for special-case override,
> > > which is what we have here?
> > >
> > > > as well as extend rpm-python to be able to expose it so yum
> > > > can do the right thing.
> > >
> > > The arch used by rpm (whether detected or overridden) is available
> > > in %{_host_cpu} macro. If something else is needed then I need to
> > > know what that would be.
> >
> > its not sufficient. it evaluates to armv7l on a hardware floating
> > point system. we would need it to be armv7hl or armv7hnl to give yum
> > the info it needs
>
> maybe _target_cpu could be used
>
> though it would need a dict of compatiable arches
>
> [dennis@panda02 ~]$ rpm --showrc |grep arm
> build arch: armv7hn
Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Oct 2011 14:00:56 -0500
Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, 17 Sep 2011 16:02:52 +0300
> Panu Matilainen wrote:
>
> > On 09/16/2011 04:58 PM, Dennis Gilmore wrote:
> > > On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote:
> > >> Oh I knew this would happen... the send-button is a magic
> > >> memory-enhancer in disguise. One (of probably many) forgotten
> > >> bits, this
> > >>
> > >> time hopefully with working address for Dennish too:
> > >>> On 09/15/2011 01:55 PM, Jon Masters wrote:
> > >>>> All of the existing stuff assumes that if we have vfpv3 on
> > >>>> ARMv7 we're going to be running in hardfp. We can keep that
> > >>>> notion around in the very short term, but we need a longer term
> > >>>> solution. And although we don't necessarily plan actual
> > >>>> parallel installs of different ABIs, it is not technically the
> > >>>> case that all ARMv7 systems are going to be running the hardfp
> > >>>> port. We may e.g. install an ARMv5 port therein.
> > >>
> > >>From what I've heard + read about the hardfp ABI, its not
> > >> actually possible to parallel-install with anything else because
> > >> even the dynamic linker has no clue whether hardfp or some other
> > >> ABI was used (see
> > >> http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to
> > >> our friends over Debian side again for a nice article :) Which
> > >> makes this a truly "unique" piece of work. I'd
> > >> love to know why it was done that way - my layman sense thinks
> > >> the compiler toolchain should be able to mark the ABI in the elf
> > >> headers (heck this is what the whole hwcap thing is about).
> > >> >
> > > ___
> > > Rpm-maint mailing list
> > > Rpm-maint@lists.rpm.org
> > > http://lists.rpm.org/mailman/listinfo/rpm-maint
> >
> > ___
> > Rpm-maint mailing list
> > Rpm-maint@lists.rpm.org
> > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > >
> > >> Since the ABI difference is apparently not recorded anywhere,
> > >> there's little chance of rpm being able to automatically do the
> > >> right thing really, and I dunno if its worth it trying to jump
> > >> through a whole lot of hoops for what seems an unachievable task.
> > >>
> > >> One simple brute-force "solution" that should work right now is
> > >> to just keep the softfp/hardfp "architectures" incompatible from
> > >> rpm POV and make the assumption that hardfp ABI will be used if
> > >> the system is capable of it. And if somebody wants to override
> > >> this assumption, that's what /etc/rpm/platform is for (allow
> > >> overriding rpm's hw detection).
> > >
> > > im not the biggest fan of this, Maybe we can hard code it somehow
> > > at compilation time?
> >
> > Care to elaborate why would you want to hardcode it instead of just
> > utilizing an existing method for special-case override, which is
> > what we have here?
> >
> > > as well as extend rpm-python to be able to expose it so yum
> > > can do the right thing.
> >
> > The arch used by rpm (whether detected or overridden) is available
> > in %{_host_cpu} macro. If something else is needed then I need to
> > know what that would be.
>
> its not sufficient. it evaluates to armv7l on a hardware floating
> point system. we would need it to be armv7hl or armv7hnl to give yum
> the info it needs
maybe _target_cpu could be used
though it would need a dict of compatiable arches
[dennis@panda02 ~]$ rpm --showrc |grep arm
build arch: armv7hnl
compatible build archs: armv7hnl armv7hl noarch
install arch : armv7hnl
compatible archs : armv7hnl armv7hl noarch
optflags : -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon
-mthumb
gpg --batch --no-verbose --no-armor --passphrase-fd 3
- -14: __isa_name armv7hnl
- -14: _archarm
- -14: _build_arch arm
- -14: _hostarmv7l-unknown-linux-gnueabi
- -14: _host_cpuarmv7l
- -11: _target armv7hnl-linux
- -11= _target_cpu armv7hnl
- -14: arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l
armv7hl arm
Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 17 Sep 2011 16:02:52 +0300
Panu Matilainen wrote:
> On 09/16/2011 04:58 PM, Dennis Gilmore wrote:
> > On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote:
> >> Oh I knew this would happen... the send-button is a magic
> >> memory-enhancer in disguise. One (of probably many) forgotten
> >> bits, this
> >>
> >> time hopefully with working address for Dennish too:
> >>> On 09/15/2011 01:55 PM, Jon Masters wrote:
> >>>> All of the existing stuff assumes that if we have vfpv3 on ARMv7
> >>>> we're going to be running in hardfp. We can keep that notion
> >>>> around in the very short term, but we need a longer term
> >>>> solution. And although we don't necessarily plan actual parallel
> >>>> installs of different ABIs, it is not technically the case that
> >>>> all ARMv7 systems are going to be running the hardfp port. We
> >>>> may e.g. install an ARMv5 port therein.
> >>
> >>From what I've heard + read about the hardfp ABI, its not
> >> actually possible to parallel-install with anything else because
> >> even the dynamic linker has no clue whether hardfp or some other
> >> ABI was used (see
> >> http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to
> >> our friends over Debian side again for a nice article :) Which
> >> makes this a truly "unique" piece of work. I'd
> >> love to know why it was done that way - my layman sense thinks the
> >> compiler toolchain should be able to mark the ABI in the elf
> >> headers (heck this is what the whole hwcap thing is about).
> >> >
> > ___
> > Rpm-maint mailing list
> > Rpm-maint@lists.rpm.org
> > http://lists.rpm.org/mailman/listinfo/rpm-maint
>
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
> >
> >> Since the ABI difference is apparently not recorded anywhere,
> >> there's little chance of rpm being able to automatically do the
> >> right thing really, and I dunno if its worth it trying to jump
> >> through a whole lot of hoops for what seems an unachievable task.
> >>
> >> One simple brute-force "solution" that should work right now is to
> >> just keep the softfp/hardfp "architectures" incompatible from rpm
> >> POV and make the assumption that hardfp ABI will be used if the
> >> system is capable of it. And if somebody wants to override this
> >> assumption, that's what /etc/rpm/platform is for (allow overriding
> >> rpm's hw detection).
> >
> > im not the biggest fan of this, Maybe we can hard code it somehow
> > at compilation time?
>
> Care to elaborate why would you want to hardcode it instead of just
> utilizing an existing method for special-case override, which is what
> we have here?
>
> > as well as extend rpm-python to be able to expose it so yum
> > can do the right thing.
>
> The arch used by rpm (whether detected or overridden) is available in
> %{_host_cpu} macro. If something else is needed then I need to know
> what that would be.
its not sufficient. it evaluates to armv7l on a hardware floating point
system. we would need it to be armv7hl or armv7hnl to give yum the info
it needs
> > we have no plans to support multi-arch here, and
> > anaconda (which we dont have yet but is underway) doesnt write out a
> > /etc/rpm/platform file any longer. ive not looked to see if that
> > code is removed from anaconda or just disabled. our plan is if you
> > install a softfloat on the system thats all you can run. and same
> > for hardfloat. while the buildsystem will have v7 builders that
> > are building for v5 and therfore running softfp, most people should
> > be running the hardfp port since its in the order of 300% faster
> > for floating point operations. the only common case of softfp use i
> > see on v7 hardware is those already running it.
>
> Anaconda stopped writing /etc/rpm/platform for "a few crazy
> architectures" when it no longer needed to do so, no reason why it
> couldn't do so again. Whether thats the best option or not I dunno.
> If there's a way (define or such) that can be used to detect which
> ABI we're compiling for then sure ifdef'ing the entire hardfp
> detection out is one option. Another option might be just ship with a
> hardwi
Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote: > Oh I knew this would happen... the send-button is a magic > memory-enhancer in disguise. One (of probably many) forgotten bits, this > > time hopefully with working address for Dennish too: > > On 09/15/2011 01:55 PM, Jon Masters wrote: > >> All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're > >> going to be running in hardfp. We can keep that notion around in the > >> very short term, but we need a longer term solution. And although we > >> don't necessarily plan actual parallel installs of different ABIs, it is > >> not technically the case that all ARMv7 systems are going to be running > >> the hardfp port. We may e.g. install an ARMv5 port therein. > > From what I've heard + read about the hardfp ABI, its not actually > possible to parallel-install with anything else because even the dynamic > linker has no clue whether hardfp or some other ABI was used (see > http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to our > friends over Debian side again for a nice article :) Which makes this a > truly "unique" piece of work. I'd love to know why it > was done that way - my layman sense thinks the compiler toolchain should > be able to mark the ABI in the elf headers (heck this is what the whole > hwcap thing is about). > Since the ABI difference is apparently not recorded anywhere, there's > little chance of rpm being able to automatically do the right thing > really, and I dunno if its worth it trying to jump through a whole lot > of hoops for what seems an unachievable task. > > One simple brute-force "solution" that should work right now is to just > keep the softfp/hardfp "architectures" incompatible from rpm POV and > make the assumption that hardfp ABI will be used if the system is > capable of it. And if somebody wants to override this assumption, that's > what /etc/rpm/platform is for (allow overriding rpm's hw detection). im not the biggest fan of this, Maybe we can hard code it somehow at compilation time? as well as extend rpm-python to be able to expose it so yum can do the right thing. we have no plans to support multi-arch here, and anaconda (which we dont have yet but is underway) doesnt write out a /etc/rpm/platform file any longer. ive not looked to see if that code is removed from anaconda or just disabled. our plan is if you install a softfloat on the system thats all you can run. and same for hardfloat. while the buildsystem will have v7 builders that are building for v5 and therfore running softfp, most people should be running the hardfp port since its in the order of 300% faster for floating point operations. the only common case of softfp use i see on v7 hardware is those already running it. Ill revise my patch to use hwcaps rather than reading /proc/cpuinfo id really like to wrap the code path around something define or something set when we build for armv7hl > Of course the entire hw-detection and arch-compatibility system is > seriously outdated and inadequate for todays needs, back in the nineties > systems were a lot less schizophrenic :) I've various vagueish ideas in > this area, but the current concept of "arch" is built so deep into tools > around rpm that fundamentally changing it is likely to be a long and > hard road. rather than having yum do its own arch detection it should be able to grab it from rpm that way both tools use the same code path and will always give the same result. We also have an issue where we are setting the isa to the -32 we really should use arm-32 and armhfp-32 or armhf-32 that way the sub arches can be used correctly. some packages especially in the softfloat port could do with having additional arches built. pixman for example could do with armv6l and armv7l builds on softfp. yum has its basearch variable that it uses which currently is arm for all arm arches but should be armhfp for the new abi, I do think that the best way to deal with the new abi is to treat it as a new seperate arch. not sure if thats true of the new x86 abi. Dennis signature.asc Description: This is a digitally signed message part. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)
Resending i posted to list from address not subscibed On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote: > Oh I knew this would happen... the send-button is a magic > memory-enhancer in disguise. One (of probably many) forgotten bits, this > > time hopefully with working address for Dennish too: > > On 09/15/2011 01:55 PM, Jon Masters wrote: > >> All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're > >> going to be running in hardfp. We can keep that notion around in the > >> very short term, but we need a longer term solution. And although we > >> don't necessarily plan actual parallel installs of different ABIs, it is > >> not technically the case that all ARMv7 systems are going to be running > >> the hardfp port. We may e.g. install an ARMv5 port therein. > > From what I've heard + read about the hardfp ABI, its not actually > possible to parallel-install with anything else because even the dynamic > linker has no clue whether hardfp or some other ABI was used (see > http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to our > friends over Debian side again for a nice article :) Which makes this a > truly "unique" piece of work. I'd love to know why it > was done that way - my layman sense thinks the compiler toolchain should > be able to mark the ABI in the elf headers (heck this is what the whole > hwcap thing is about). > Since the ABI difference is apparently not recorded anywhere, there's > little chance of rpm being able to automatically do the right thing > really, and I dunno if its worth it trying to jump through a whole lot > of hoops for what seems an unachievable task. > > One simple brute-force "solution" that should work right now is to just > keep the softfp/hardfp "architectures" incompatible from rpm POV and > make the assumption that hardfp ABI will be used if the system is > capable of it. And if somebody wants to override this assumption, that's > what /etc/rpm/platform is for (allow overriding rpm's hw detection). im not the biggest fan of this, Maybe we can hard code it somehow at compilation time? as well as extend rpm-python to be able to expose it so yum can do the right thing. we have no plans to support multi-arch here, and anaconda (which we dont have yet but is underway) doesnt write out a /etc/rpm/platform file any longer. ive not looked to see if that code is removed from anaconda or just disabled. our plan is if you install a softfloat on the system thats all you can run. and same for hardfloat. while the buildsystem will have v7 builders that are building for v5 and therfore running softfp, most people should be running the hardfp port since its in the order of 300% faster for floating point operations. the only common case of softfp use i see on v7 hardware is those already running it. Ill revise my patch to use hwcaps rather than reading /proc/cpuinfo id really like to wrap the code path around something define or something set when we build for armv7hl > Of course the entire hw-detection and arch-compatibility system is > seriously outdated and inadequate for todays needs, back in the nineties > systems were a lot less schizophrenic :) I've various vagueish ideas in > this area, but the current concept of "arch" is built so deep into tools > around rpm that fundamentally changing it is likely to be a long and > hard road. rather than having yum do its own arch detection it should be able to grab it from rpm that way both tools use the same code path and will always give the same result. We also have an issue where we are setting the isa to the -32 we really should use arm-32 and armhfp-32 or armhf-32 that way the sub arches can be used correctly. some packages especially in the softfloat port could do with having additional arches built. pixman for example could do with armv6l and armv7l builds on softfp. yum has its basearch variable that it uses which currently is arm for all arm arches but should be armhfp for the new abi, I do think that the best way to deal with the new abi is to treat it as a new seperate arch. not sure if thats true of the new x86 abi. Dennis signature.asc Description: This is a digitally signed message part. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
