| Message ID | 1395769952-64221-1-git-send-email-Vincent.Riera@imgtec.com |
|---|---|
| State | Superseded |
| Headers | show |
On 25/03/14 18:52, Vicente Olivert Riera wrote: > Building o32 ELF files for MIPS64 is an exotic configuration that nobody > should be using. If o32 is required, then is better if it's built for > MIPS 32-bit cores so only 32-bit instructions will be used leading to a > more efficient o32 usage. > > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> > --- > arch/Config.in.mips | 12 +++++++----- > 1 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/Config.in.mips b/arch/Config.in.mips > index d9c0c02..f558705 100644 > --- a/arch/Config.in.mips > +++ b/arch/Config.in.mips > @@ -38,15 +38,12 @@ endchoice > > choice > prompt "Target ABI" > - depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el > - default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64 > - default BR2_MIPS_NABI32 if BR2_ARCH_IS_64 > + depends on BR2_mips64 || BR2_mips64el > + default BR2_MIPS_NABI32 > > help > Application Binary Interface to use > > -config BR2_MIPS_OABI32 > - bool "o32" > config BR2_MIPS_NABI32 > bool "n32" > depends on BR2_ARCH_IS_64 > @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH > default "mips64" if BR2_mips_64 > default "mips64r2" if BR2_mips_64r2 > > +config BR2_MIPS_OABI32 > + bool > + default y if BR2_mips || BR2_mipsel > + default n if BR2_mips64 || BR2_mips64el The default n isn't needed - that is the default already in all other cases. > + > config BR2_GCC_TARGET_ABI > default "32" if BR2_MIPS_OABI32 > default "n32" if BR2_MIPS_NABI32 > Normally we should have a Config.in.legacy entry to catch old .configs that have o32 for a mips64 target. However, that is not possible now. Therefore, it should be captured in the release notes. To make sure that Peter doesn't forget, can you add this to the top of CHANGES? 2014.05, Not yet released: Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building o32 ELF files for MIPS64 is an exotic configuration that nobody should be using. If o32 is required, then is better if it's built for MIPS 32-bit cores so only 32-bit instructions will be used leading to a more efficient o32 usage. Regards, Arnout
On 03/25/2014 16:02, Arnout Vandecappelle wrote: > On 25/03/14 18:52, Vicente Olivert Riera wrote: >> Building o32 ELF files for MIPS64 is an exotic configuration that nobody >> should be using. If o32 is required, then is better if it's built for >> MIPS 32-bit cores so only 32-bit instructions will be used leading to a >> more efficient o32 usage. >> >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> >> --- >> arch/Config.in.mips | 12 +++++++----- >> 1 files changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/arch/Config.in.mips b/arch/Config.in.mips >> index d9c0c02..f558705 100644 >> --- a/arch/Config.in.mips >> +++ b/arch/Config.in.mips >> @@ -38,15 +38,12 @@ endchoice >> >> choice >> prompt "Target ABI" >> - depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el >> - default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64 >> - default BR2_MIPS_NABI32 if BR2_ARCH_IS_64 >> + depends on BR2_mips64 || BR2_mips64el >> + default BR2_MIPS_NABI32 >> >> help >> Application Binary Interface to use >> >> -config BR2_MIPS_OABI32 >> - bool "o32" >> config BR2_MIPS_NABI32 >> bool "n32" >> depends on BR2_ARCH_IS_64 >> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH >> default "mips64" if BR2_mips_64 >> default "mips64r2" if BR2_mips_64r2 >> >> +config BR2_MIPS_OABI32 >> + bool >> + default y if BR2_mips || BR2_mipsel >> + default n if BR2_mips64 || BR2_mips64el > > The default n isn't needed - that is the default already in all other cases. > >> + >> config BR2_GCC_TARGET_ABI >> default "32" if BR2_MIPS_OABI32 >> default "n32" if BR2_MIPS_NABI32 >> > > Normally we should have a Config.in.legacy entry to catch old .configs > that have o32 for a mips64 target. However, that is not possible now. > Therefore, it should be captured in the release notes. To make sure that > Peter doesn't forget, can you add this to the top of CHANGES? > > > 2014.05, Not yet released: > > Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building > o32 ELF files for MIPS64 is an exotic configuration that nobody should be > using. If o32 is required, then is better if it's built for MIPS 32-bit > cores so only 32-bit instructions will be used leading to a more > efficient o32 usage. Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do have a somewhat-working n32 chroot on the same box. Additionally, isn't o32 the ABI that Debian still builds for most of their mips/mipsel targets? I guess for newer MIPS hardware, this is definitely sensible, but given the wide availability of old SGI hardware on eBay, it's far from exotic. I also believe Debian still supports DEC systems, which are even older. I still plan on looking at fixing the MIPS-II to MIPS-IV issue I raised a few weeks ago, but I've been tied up in other projects. So if there is some legacy way to retain this capability, maybe by defining an SGI-specific target at some point, that'd be great. It'll at least give me a starting port to isolate the legacy stuff so that it only applies to this old hardware and doesn't impede anyone working with newer hardware. Food for thought :)
On 03/26/2014 12:14 AM, Joshua Kinard wrote: > On 03/25/2014 16:02, Arnout Vandecappelle wrote: >> On 25/03/14 18:52, Vicente Olivert Riera wrote: >>> Building o32 ELF files for MIPS64 is an exotic configuration that nobody >>> should be using. If o32 is required, then is better if it's built for >>> MIPS 32-bit cores so only 32-bit instructions will be used leading to a >>> more efficient o32 usage. >>> >>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> >>> --- >>> arch/Config.in.mips | 12 +++++++----- >>> 1 files changed, 7 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips >>> index d9c0c02..f558705 100644 >>> --- a/arch/Config.in.mips >>> +++ b/arch/Config.in.mips >>> @@ -38,15 +38,12 @@ endchoice >>> >>> choice >>> prompt "Target ABI" >>> - depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el >>> - default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64 >>> - default BR2_MIPS_NABI32 if BR2_ARCH_IS_64 >>> + depends on BR2_mips64 || BR2_mips64el >>> + default BR2_MIPS_NABI32 >>> >>> help >>> Application Binary Interface to use >>> >>> -config BR2_MIPS_OABI32 >>> - bool "o32" >>> config BR2_MIPS_NABI32 >>> bool "n32" >>> depends on BR2_ARCH_IS_64 >>> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH >>> default "mips64" if BR2_mips_64 >>> default "mips64r2" if BR2_mips_64r2 >>> >>> +config BR2_MIPS_OABI32 >>> + bool >>> + default y if BR2_mips || BR2_mipsel >>> + default n if BR2_mips64 || BR2_mips64el >> >> The default n isn't needed - that is the default already in all other cases. >> >>> + >>> config BR2_GCC_TARGET_ABI >>> default "32" if BR2_MIPS_OABI32 >>> default "n32" if BR2_MIPS_NABI32 >>> >> >> Normally we should have a Config.in.legacy entry to catch old .configs >> that have o32 for a mips64 target. However, that is not possible now. >> Therefore, it should be captured in the release notes. To make sure that >> Peter doesn't forget, can you add this to the top of CHANGES? >> >> >> 2014.05, Not yet released: >> >> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >> o32 ELF files for MIPS64 is an exotic configuration that nobody should be >> using. If o32 is required, then is better if it's built for MIPS 32-bit >> cores so only 32-bit instructions will be used leading to a more >> efficient o32 usage. > > Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels > (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do have > a somewhat-working n32 chroot on the same box. Additionally, isn't o32 the > ABI that Debian still builds for most of their mips/mipsel targets? We are talking about using 64-bit instructions in *userland* while maintaining the o32 ABI semantics. Well, this is definitely an exotic configuration. We are not talking about 64-bit kernels + o32 userland. An o32 userland usually comes from mips32 and you usually have only 32-bit instructions there.
On 03/26/2014 02:19 PM, Markos Chandras wrote: > On 03/26/2014 12:14 AM, Joshua Kinard wrote: >> On 03/25/2014 16:02, Arnout Vandecappelle wrote: >>> On 25/03/14 18:52, Vicente Olivert Riera wrote: >>>> Building o32 ELF files for MIPS64 is an exotic configuration that >>>> nobody >>>> should be using. If o32 is required, then is better if it's built for >>>> MIPS 32-bit cores so only 32-bit instructions will be used leading to a >>>> more efficient o32 usage. >>>> >>>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> >>>> --- >>>> arch/Config.in.mips | 12 +++++++----- >>>> 1 files changed, 7 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/arch/Config.in.mips b/arch/Config.in.mips >>>> index d9c0c02..f558705 100644 >>>> --- a/arch/Config.in.mips >>>> +++ b/arch/Config.in.mips >>>> @@ -38,15 +38,12 @@ endchoice >>>> >>>> choice >>>> prompt "Target ABI" >>>> - depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el >>>> - default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64 >>>> - default BR2_MIPS_NABI32 if BR2_ARCH_IS_64 >>>> + depends on BR2_mips64 || BR2_mips64el >>>> + default BR2_MIPS_NABI32 >>>> >>>> help >>>> Application Binary Interface to use >>>> >>>> -config BR2_MIPS_OABI32 >>>> - bool "o32" >>>> config BR2_MIPS_NABI32 >>>> bool "n32" >>>> depends on BR2_ARCH_IS_64 >>>> @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH >>>> default "mips64" if BR2_mips_64 >>>> default "mips64r2" if BR2_mips_64r2 >>>> >>>> +config BR2_MIPS_OABI32 >>>> + bool >>>> + default y if BR2_mips || BR2_mipsel >>>> + default n if BR2_mips64 || BR2_mips64el >>> >>> The default n isn't needed - that is the default already in all >>> other cases. >>> >>>> + >>>> config BR2_GCC_TARGET_ABI >>>> default "32" if BR2_MIPS_OABI32 >>>> default "n32" if BR2_MIPS_NABI32 >>>> >>> >>> Normally we should have a Config.in.legacy entry to catch old .configs >>> that have o32 for a mips64 target. However, that is not possible now. >>> Therefore, it should be captured in the release notes. To make sure that >>> Peter doesn't forget, can you add this to the top of CHANGES? >>> >>> >>> 2014.05, Not yet released: >>> >>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >>> o32 ELF files for MIPS64 is an exotic configuration that nobody >>> should be >>> using. If o32 is required, then is better if it's built for MIPS 32-bit >>> cores so only 32-bit instructions will be used leading to a more >>> efficient o32 usage. >> >> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels >> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I >> do have >> a somewhat-working n32 chroot on the same box. Additionally, isn't >> o32 the >> ABI that Debian still builds for most of their mips/mipsel targets? > > We are talking about using 64-bit instructions in *userland* while > maintaining the o32 ABI semantics. Well, this is definitely an exotic > configuration. We are not talking about 64-bit kernels + o32 userland. > An o32 userland usually comes from mips32 and you usually have only > 32-bit instructions there. > V3 sent: http://patchwork.ozlabs.org/patch/333959/
Hi Joshua, On 26/03/14 15:19, Markos Chandras wrote: > On 03/26/2014 12:14 AM, Joshua Kinard wrote: >> On 03/25/2014 16:02, Arnout Vandecappelle wrote: [snip] >>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be >>> using. If o32 is required, then is better if it's built for MIPS 32-bit >>> cores so only 32-bit instructions will be used leading to a more >>> efficient o32 usage. >> >> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels >> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do >> have >> a somewhat-working n32 chroot on the same box. Additionally, isn't o32 So the mips64 n32 userspace created by buildroot doesn't work completely, just somewhat? >> the >> ABI that Debian still builds for most of their mips/mipsel targets? What Debian does is really not relevant here... > > We are talking about using 64-bit instructions in *userland* while > maintaining the o32 ABI semantics. Well, this is definitely an exotic > configuration. We are not talking about 64-bit kernels + o32 userland. > An o32 userland usually comes from mips32 and you usually have only > 32-bit instructions there. Joshua, if you agree with this reasoning, could you ack Vicente's patch? Regards, Arnout
On 03/26/2014 10:19, Markos Chandras wrote: > On 03/26/2014 12:14 AM, Joshua Kinard wrote: >> On 03/25/2014 16:02, Arnout Vandecappelle wrote: >>> On 25/03/14 18:52, Vicente Olivert Riera wrote: [snip] >>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be >>> using. If o32 is required, then is better if it's built for MIPS 32-bit >>> cores so only 32-bit instructions will be used leading to a more >>> efficient o32 usage. >> >> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels >> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do have >> a somewhat-working n32 chroot on the same box. Additionally, isn't o32 the >> ABI that Debian still builds for most of their mips/mipsel targets? > > We are talking about using 64-bit instructions in *userland* while > maintaining the o32 ABI semantics. Well, this is definitely an exotic > configuration. We are not talking about 64-bit kernels + o32 userland. > An o32 userland usually comes from mips32 and you usually have only 32-bit > instructions there. I think the mixup I am having is the "MIPS64" that Vincent is referring to is the ISA, e.g., mips64r[12], not "MIPS64" as in "64bit MIPS", right?
On 03/26/2014 13:17, Arnout Vandecappelle wrote: > > Hi Joshua, > > On 26/03/14 15:19, Markos Chandras wrote: >> On 03/26/2014 12:14 AM, Joshua Kinard wrote: >>> On 03/25/2014 16:02, Arnout Vandecappelle wrote: > [snip] >>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be >>>> using. If o32 is required, then is better if it's built for MIPS 32-bit >>>> cores so only 32-bit instructions will be used leading to a more >>>> efficient o32 usage. >>> >>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels >>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do >>> have >>> a somewhat-working n32 chroot on the same box. Additionally, isn't o32 > > So the mips64 n32 userspace created by buildroot doesn't work > completely, just somewhat? No, "somewhat" means I haven't powered that machine up in a while and updated it. It boots into an o32 install I've had since 2005 (and am loathe to replace just yet, at least as long as the disks stay alive), and I chroot into a separate n32 root. It's got an old 350MHz RM7000 CPU (PMC-Sierra), so updating can take a long time for just the o32 root (gcc is ~17hrs these days. Used to be ~2.5hrs in the gcc-3.4.x days). Once that's updated, I then update the n32 root. Almost had that done until a recent snow storm knocked my power out, and I never resumed the update. >> We are talking about using 64-bit instructions in *userland* while >> maintaining the o32 ABI semantics. Well, this is definitely an exotic >> configuration. We are not talking about 64-bit kernels + o32 userland. >> An o32 userland usually comes from mips32 and you usually have only >> 32-bit instructions there. > > Joshua, if you agree with this reasoning, could you ack Vicente's patch? Let me get clarification on what "MIPS64" Vincent was referring to first. It's easy to mix that up. I was assuming he meant o32 userland + mips64 kernel, which I know still works, even though it is very inefficient (using just half of your available CPU registers). If he's referring to the ISA of MIPS64 (or as I read it, mips64r1/mips64r2), then yeah, it's not a problem at all. Though I am not an authority on MIPS' capabilities outside of the SGI hardware lineup, as that's all that I have available to play with.
On 03/26/2014 11:45 PM, Joshua Kinard wrote: > On 03/26/2014 13:17, Arnout Vandecappelle wrote: >> >> Hi Joshua, >> >> On 26/03/14 15:19, Markos Chandras wrote: >>> On 03/26/2014 12:14 AM, Joshua Kinard wrote: >>>> On 03/25/2014 16:02, Arnout Vandecappelle wrote: >> [snip] >>>>> Support for MIPS o32 ABI on MIPS-64 targets has been removed. Building >>>>> o32 ELF files for MIPS64 is an exotic configuration that nobody should be >>>>> using. If o32 is required, then is better if it's built for MIPS 32-bit >>>>> cores so only 32-bit instructions will be used leading to a more >>>>> efficient o32 usage. >>>> >>>> Just to point out, I wouldn't call this "exotic" -- o32 on mips64 kernels >>>> (MIPS-IV ISA) is what I run on my SGI O2 under Gentoo. That said, I do >>>> have >>>> a somewhat-working n32 chroot on the same box. Additionally, isn't o32 >> >> So the mips64 n32 userspace created by buildroot doesn't work >> completely, just somewhat? > > No, "somewhat" means I haven't powered that machine up in a while and > updated it. It boots into an o32 install I've had since 2005 (and am loathe > to replace just yet, at least as long as the disks stay alive), and I chroot > into a separate n32 root. It's got an old 350MHz RM7000 CPU (PMC-Sierra), > so updating can take a long time for just the o32 root (gcc is ~17hrs these > days. Used to be ~2.5hrs in the gcc-3.4.x days). Once that's updated, I > then update the n32 root. Almost had that done until a recent snow storm > knocked my power out, and I never resumed the update. > > >>> We are talking about using 64-bit instructions in *userland* while >>> maintaining the o32 ABI semantics. Well, this is definitely an exotic >>> configuration. We are not talking about 64-bit kernels + o32 userland. >>> An o32 userland usually comes from mips32 and you usually have only >>> 32-bit instructions there. >> >> Joshua, if you agree with this reasoning, could you ack Vicente's patch? > > Let me get clarification on what "MIPS64" Vincent was referring to first. > It's easy to mix that up. I was assuming he meant o32 userland + mips64 > kernel, which I know still works, even though it is very inefficient (using > just half of your available CPU registers). If he's referring to the ISA of > MIPS64 (or as I read it, mips64r1/mips64r2), then yeah, it's not a problem > at all. Though I am not an authority on MIPS' capabilities outside of the > SGI hardware lineup, as that's all that I have available to play with. > > Yes, maybe the commit message was confusing. We definitely did not mean mips64 kernel + o32 userland. We meant 64-bit userland + o32 ABI. So I guess we are all good here :)
diff --git a/arch/Config.in.mips b/arch/Config.in.mips index d9c0c02..f558705 100644 --- a/arch/Config.in.mips +++ b/arch/Config.in.mips @@ -38,15 +38,12 @@ endchoice choice prompt "Target ABI" - depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el - default BR2_MIPS_OABI32 if !BR2_ARCH_IS_64 - default BR2_MIPS_NABI32 if BR2_ARCH_IS_64 + depends on BR2_mips64 || BR2_mips64el + default BR2_MIPS_NABI32 help Application Binary Interface to use -config BR2_MIPS_OABI32 - bool "o32" config BR2_MIPS_NABI32 bool "n32" depends on BR2_ARCH_IS_64 @@ -86,6 +83,11 @@ config BR2_GCC_TARGET_ARCH default "mips64" if BR2_mips_64 default "mips64r2" if BR2_mips_64r2 +config BR2_MIPS_OABI32 + bool + default y if BR2_mips || BR2_mipsel + default n if BR2_mips64 || BR2_mips64el + config BR2_GCC_TARGET_ABI default "32" if BR2_MIPS_OABI32 default "n32" if BR2_MIPS_NABI32
Building o32 ELF files for MIPS64 is an exotic configuration that nobody should be using. If o32 is required, then is better if it's built for MIPS 32-bit cores so only 32-bit instructions will be used leading to a more efficient o32 usage. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> --- arch/Config.in.mips | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-)