* [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit @ 2023-05-06 8:37 YunQiang Su 2023-05-06 8:42 ` Jiaxun Yang 0 siblings, 1 reply; 17+ messages in thread From: YunQiang Su @ 2023-05-06 8:37 UTC (permalink / raw) To: binutils; +Cc: syq, macro, xry111, richard.sandiford, jiaxun.yang, YunQiang Su When configure with triples mipsisa[32,64]r6[el,], the march value is pinned to a fix value if not given explicitly. for example mipsisa32r6-linux-gnu -n32 xx.s will complains that: -march=mips32r6 is not compatible with the selected ABI Since we are using these triples as a regular linux distributions, let's alter march according to ABI. --- gas/config/tc-mips.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c index 8a970ceada2..d99736df26a 100644 --- a/gas/config/tc-mips.c +++ b/gas/config/tc-mips.c @@ -20247,6 +20247,24 @@ mips_parse_cpu (const char *option, const char *cpu_string) : ISA_MIPS1); } + /* mipsisa32r6-linux-gnu refuses -n32/-64 swtiches: + -march=mips32r6 is not compatible with the selected ABI + Let's workaround it when -march options are not given explicitly. + We treat it some like -march=from-abi */ + if ((strcasecmp (cpu_string, "mips32r6") == 0 || strcasecmp (cpu_string, "mips64r6") == 0) + && strcasecmp (option, "default CPU") == 0) + { + if (ABI_NEEDS_32BIT_REGS (mips_abi)) + return mips_cpu_info_from_isa (ISA_MIPS32R6); + + if (ABI_NEEDS_64BIT_REGS (mips_abi)) + return mips_cpu_info_from_isa (ISA_MIPS64R6); + + if (file_mips_opts.gp >= 0) + return mips_cpu_info_from_isa (file_mips_opts.gp == 32 + ? ISA_MIPS32R6 : ISA_MIPS64R6); + } + /* 'default' has traditionally been a no-op. Probably not very useful. */ if (strcasecmp (cpu_string, "default") == 0) return 0; -- 2.30.2 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-06 8:37 [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit YunQiang Su @ 2023-05-06 8:42 ` Jiaxun Yang 2023-05-06 8:52 ` YunQiang Su 0 siblings, 1 reply; 17+ messages in thread From: Jiaxun Yang @ 2023-05-06 8:42 UTC (permalink / raw) To: YunQiang Su Cc: Binutils, YunQiang Su, Maciej W. Rozycki, Xi Ruoyao, richard.sandiford > 2023年5月6日 09:37,YunQiang Su <yunqiang.su@cipunited.com> 写道: > > When configure with triples mipsisa[32,64]r6[el,], the march value > is pinned to a fix value if not given explicitly. for example > mipsisa32r6-linux-gnu -n32 xx.s > will complains that: > -march=mips32r6 is not compatible with the selected ABI > > Since we are using these triples as a regular linux distributions, > let's alter march according to ABI. Hi, Hmm, why people wants to build n32 binary on mips32r6 CPU? For multiline folks they should use mipsisa64r6 base triple which will accept all 3 ABIs. Thanks Jiaxun > --- > gas/config/tc-mips.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c > index 8a970ceada2..d99736df26a 100644 > --- a/gas/config/tc-mips.c > +++ b/gas/config/tc-mips.c > @@ -20247,6 +20247,24 @@ mips_parse_cpu (const char *option, const char *cpu_string) > : ISA_MIPS1); > } > > + /* mipsisa32r6-linux-gnu refuses -n32/-64 swtiches: > + -march=mips32r6 is not compatible with the selected ABI > + Let's workaround it when -march options are not given explicitly. > + We treat it some like -march=from-abi */ > + if ((strcasecmp (cpu_string, "mips32r6") == 0 || strcasecmp (cpu_string, "mips64r6") == 0) > + && strcasecmp (option, "default CPU") == 0) > + { > + if (ABI_NEEDS_32BIT_REGS (mips_abi)) > + return mips_cpu_info_from_isa (ISA_MIPS32R6); > + > + if (ABI_NEEDS_64BIT_REGS (mips_abi)) > + return mips_cpu_info_from_isa (ISA_MIPS64R6); > + > + if (file_mips_opts.gp >= 0) > + return mips_cpu_info_from_isa (file_mips_opts.gp == 32 > + ? ISA_MIPS32R6 : ISA_MIPS64R6); > + } > + > /* 'default' has traditionally been a no-op. Probably not very useful. */ > if (strcasecmp (cpu_string, "default") == 0) > return 0; > -- > 2.30.2 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-06 8:42 ` Jiaxun Yang @ 2023-05-06 8:52 ` YunQiang Su 2023-05-06 9:15 ` Jiaxun Yang 0 siblings, 1 reply; 17+ messages in thread From: YunQiang Su @ 2023-05-06 8:52 UTC (permalink / raw) To: Jiaxun Yang Cc: YunQiang Su, Binutils, Maciej W. Rozycki, Xi Ruoyao, richard.sandiford Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月6日周六 16:43写道: > > > > > 2023年5月6日 09:37,YunQiang Su <yunqiang.su@cipunited.com> 写道: > > > > When configure with triples mipsisa[32,64]r6[el,], the march value > > is pinned to a fix value if not given explicitly. for example > > mipsisa32r6-linux-gnu -n32 xx.s > > will complains that: > > -march=mips32r6 is not compatible with the selected ABI > > > > Since we are using these triples as a regular linux distributions, > > let's alter march according to ABI. > > Hi, > > Hmm, why people wants to build n32 binary on mips32r6 CPU? I guess o32 toolchain should not work only for 32bit CPU? At seem time, this patch can solve some testcases in binutils-all when configured with --target=mipsisa32r6-linux-gnu > For multiline folks they should use mipsisa64r6 base triple which will accept > all 3 ABIs. > > Thanks > Jiaxun > > > > --- > > gas/config/tc-mips.c | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c > > index 8a970ceada2..d99736df26a 100644 > > --- a/gas/config/tc-mips.c > > +++ b/gas/config/tc-mips.c > > @@ -20247,6 +20247,24 @@ mips_parse_cpu (const char *option, const char *cpu_string) > > : ISA_MIPS1); > > } > > > > + /* mipsisa32r6-linux-gnu refuses -n32/-64 swtiches: > > + -march=mips32r6 is not compatible with the selected ABI > > + Let's workaround it when -march options are not given explicitly. > > + We treat it some like -march=from-abi */ > > + if ((strcasecmp (cpu_string, "mips32r6") == 0 || strcasecmp (cpu_string, "mips64r6") == 0) > > + && strcasecmp (option, "default CPU") == 0) > > + { > > + if (ABI_NEEDS_32BIT_REGS (mips_abi)) > > + return mips_cpu_info_from_isa (ISA_MIPS32R6); > > + > > + if (ABI_NEEDS_64BIT_REGS (mips_abi)) > > + return mips_cpu_info_from_isa (ISA_MIPS64R6); > > + > > + if (file_mips_opts.gp >= 0) > > + return mips_cpu_info_from_isa (file_mips_opts.gp == 32 > > + ? ISA_MIPS32R6 : ISA_MIPS64R6); > > + } > > + > > /* 'default' has traditionally been a no-op. Probably not very useful. */ > > if (strcasecmp (cpu_string, "default") == 0) > > return 0; > > -- > > 2.30.2 > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-06 8:52 ` YunQiang Su @ 2023-05-06 9:15 ` Jiaxun Yang 2023-05-07 18:17 ` Maciej W. Rozycki 0 siblings, 1 reply; 17+ messages in thread From: Jiaxun Yang @ 2023-05-06 9:15 UTC (permalink / raw) To: YunQiang Su Cc: YunQiang Su, Binutils, Maciej W. Rozycki, Xi Ruoyao, richard.sandiford > 2023年5月6日 09:52,YunQiang Su <syq@debian.org> 写道: > > Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月6日周六 16:43写道: >> >> >> >>> 2023年5月6日 09:37,YunQiang Su <yunqiang.su@cipunited.com> 写道: >>> >>> When configure with triples mipsisa[32,64]r6[el,], the march value >>> is pinned to a fix value if not given explicitly. for example >>> mipsisa32r6-linux-gnu -n32 xx.s >>> will complains that: >>> -march=mips32r6 is not compatible with the selected ABI >>> >>> Since we are using these triples as a regular linux distributions, >>> let's alter march according to ABI. >> >> Hi, >> >> Hmm, why people wants to build n32 binary on mips32r6 CPU? > > I guess o32 toolchain should not work only for 32bit CPU? In this case people should override -march option themself, not rely on random toolchain hacks, since it’s not determinant from user’s perspective what “fallback” march it will be, especially in case the toolchain is not designed for base ISA. > > At seem time, this patch can solve some testcases in binutils-all > when configured with > --target=mipsisa32r6-linux-gnu I think we’d better fix the test case. Thanks Jiaxun ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-06 9:15 ` Jiaxun Yang @ 2023-05-07 18:17 ` Maciej W. Rozycki 2023-05-07 18:34 ` Jiaxun Yang 0 siblings, 1 reply; 17+ messages in thread From: Maciej W. Rozycki @ 2023-05-07 18:17 UTC (permalink / raw) To: Jiaxun Yang Cc: YunQiang Su, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford On Sat, 6 May 2023, Jiaxun Yang wrote: > >> Hmm, why people wants to build n32 binary on mips32r6 CPU? > > > > I guess o32 toolchain should not work only for 32bit CPU? > > In this case people should override -march option themself, not rely on random > toolchain hacks, since it’s not determinant from user’s perspective what “fallback” > march it will be, especially in case the toolchain is not designed for base ISA. Seconded. If anyhow, I'd suggest changing the arrangement the GCC way, that is by adding `--with-arch-32=' and `--with-arch-64=' configuration options. I'm not terribly convinced however that would be a worthwhile improvement, because GAS shouldn't normally be invoked directly, and when called via the GCC driver the driver will do the right thing. YunQiang, do you actually have a use case for invoking GAS directly? I only do it when debugging GAS, which is sort of irrelevant. For normal compilations I never do it. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-07 18:17 ` Maciej W. Rozycki @ 2023-05-07 18:34 ` Jiaxun Yang 2023-05-07 19:01 ` Maciej W. Rozycki ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Jiaxun Yang @ 2023-05-07 18:34 UTC (permalink / raw) To: Maciej W. Rozycki Cc: YunQiang Su, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford > 2023年5月7日 19:17,Maciej W. Rozycki <macro@orcam.me.uk> 写道: > > On Sat, 6 May 2023, Jiaxun Yang wrote: > >>>> Hmm, why people wants to build n32 binary on mips32r6 CPU? >>> >>> I guess o32 toolchain should not work only for 32bit CPU? >> >> In this case people should override -march option themself, not rely on random >> toolchain hacks, since it’s not determinant from user’s perspective what “fallback” >> march it will be, especially in case the toolchain is not designed for base ISA. > > Seconded. If anyhow, I'd suggest changing the arrangement the GCC way, > that is by adding `--with-arch-32=' and `--with-arch-64=' configuration > options. I'm not terribly convinced however that would be a worthwhile > improvement, because GAS shouldn't normally be invoked directly, and when > called via the GCC driver the driver will do the right thing. > > YunQiang, do you actually have a use case for invoking GAS directly? I > only do it when debugging GAS, which is sort of irrelevant. For normal > compilations I never do it. The issue was raised by Glib[1], they are involving `ld` directly. I recall v8 was generating embedded data as assembly directives and then invoking as to generate object file. They claimed it’s faster than GCC. I think it make sense to get this “workaround” done in GAS/LD, but not in this way. `--with-arch-32=' and `--with-arch-64=` method fits the purpose better. Thanks Jiaxun [1]: https://gitlab.gnome.org/GNOME/glib/-/issues/2768 > > Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-07 18:34 ` Jiaxun Yang @ 2023-05-07 19:01 ` Maciej W. Rozycki 2023-05-08 9:16 ` YunQiang Su 2023-05-08 9:18 ` YunQiang Su 2023-05-08 9:39 ` Andreas Schwab 2 siblings, 1 reply; 17+ messages in thread From: Maciej W. Rozycki @ 2023-05-07 19:01 UTC (permalink / raw) To: Jiaxun Yang Cc: YunQiang Su, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford On Sun, 7 May 2023, Jiaxun Yang wrote: > > YunQiang, do you actually have a use case for invoking GAS directly? I > > only do it when debugging GAS, which is sort of irrelevant. For normal > > compilations I never do it. > > The issue was raised by Glib[1], they are involving `ld` directly. That's a bug in Glib then, LD is not supposed to be invoked directly with user compilations. For one correct multilib options won't be applied and if Glib strives to extract them from GCC invocation somehow, then good luck! The issue claims they want to call `ld -r' to get a relocatable link. Why don't they just call `gcc -r' to the same effect in a supported way? Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-07 19:01 ` Maciej W. Rozycki @ 2023-05-08 9:16 ` YunQiang Su 2023-05-08 12:25 ` Maciej W. Rozycki 0 siblings, 1 reply; 17+ messages in thread From: YunQiang Su @ 2023-05-08 9:16 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford Maciej W. Rozycki <macro@orcam.me.uk> 于2023年5月8日周一 03:01写道: > > On Sun, 7 May 2023, Jiaxun Yang wrote: > > > > YunQiang, do you actually have a use case for invoking GAS directly? I > > > only do it when debugging GAS, which is sort of irrelevant. For normal > > > compilations I never do it. > > > > The issue was raised by Glib[1], they are involving `ld` directly. > > That's a bug in Glib then, LD is not supposed to be invoked directly with > user compilations. For one correct multilib options won't be applied and > if Glib strives to extract them from GCC invocation somehow, then good > luck! > As my experience of working on Linux distributions, lots of softwares invoke gas/ld directly. For Glib's aspect, it expects the system's toolchain so the right thing, So it is not a bug. > The issue claims they want to call `ld -r' to get a relocatable link. > Why don't they just call `gcc -r' to the same effect in a supported way? > In fact it doesn't work: syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped > Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 9:16 ` YunQiang Su @ 2023-05-08 12:25 ` Maciej W. Rozycki 2023-05-08 13:00 ` YunQiang Su 0 siblings, 1 reply; 17+ messages in thread From: Maciej W. Rozycki @ 2023-05-08 12:25 UTC (permalink / raw) To: YunQiang Su Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford On Mon, 8 May 2023, YunQiang Su wrote: > > That's a bug in Glib then, LD is not supposed to be invoked directly with > > user compilations. For one correct multilib options won't be applied and > > if Glib strives to extract them from GCC invocation somehow, then good > > luck! > > As my experience of working on Linux distributions, lots of softwares invoke > gas/ld directly. It doesn't make them correct. Lots of software packages, though maybe fewer these days, also break in a cross-compilation environment. Both cases are unfortunate, but not our problem to work around. > > The issue claims they want to call `ld -r' to get a relocatable link. > > Why don't they just call `gcc -r' to the same effect in a supported way? > > In fact it doesn't work: > > syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o > xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped You'll need to debug it them, because LD overall is supposed to propagate ISA flags correctly, and it actually works here: $ cat foo.s foo: move $2, $3 $ mips-linux-gnu-gcc -march=mips32r2 -c foo.s -o foo-r2.o $ mips-linux-gnu-gcc -march=mips32r6 -c foo.s -o foo-r6.o $ mips-linux-gnu-gcc -march=mips32r2 -r foo-r2.o -o foo-r2-r.o $ mips-linux-gnu-gcc -march=mips32r6 -r foo-r6.o -o foo-r6-r.o $ file foo*.o foo-r2-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped foo-r2.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped foo-r6-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped foo-r6.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped $ mips-linux-gnu-ld --version GNU ld (GNU Binutils) 2.39.50.20221112 [...] Maybe it's a recent regression? Or is glib trying to make an ELF object out of a non-ELF one, so input doesn't have correct flags/attributes set? That's not really supported, they need to get at their input data through an assembly source, via the `.incbin' pseudo-op (invented many years ago to solve this very problem). I was bitten by this issue decades ago too, even before `.incbin' existed. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 12:25 ` Maciej W. Rozycki @ 2023-05-08 13:00 ` YunQiang Su 2023-05-08 14:43 ` Maciej W. Rozycki 0 siblings, 1 reply; 17+ messages in thread From: YunQiang Su @ 2023-05-08 13:00 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford Maciej W. Rozycki <macro@orcam.me.uk> 于2023年5月8日周一 20:25写道: > > On Mon, 8 May 2023, YunQiang Su wrote: > > > > That's a bug in Glib then, LD is not supposed to be invoked directly with > > > user compilations. For one correct multilib options won't be applied and > > > if Glib strives to extract them from GCC invocation somehow, then good > > > luck! > > > > As my experience of working on Linux distributions, lots of softwares invoke > > gas/ld directly. > > It doesn't make them correct. Lots of software packages, though maybe > fewer these days, also break in a cross-compilation environment. Both > cases are unfortunate, but not our problem to work around. > > > > The issue claims they want to call `ld -r' to get a relocatable link. > > > Why don't they just call `gcc -r' to the same effect in a supported way? > > > > In fact it doesn't work: > > > > syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o > > xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped > > You'll need to debug it them, because LD overall is supposed to propagate > ISA flags correctly, and it actually works here: > > $ cat foo.s > foo: > move $2, $3 > $ mips-linux-gnu-gcc -march=mips32r2 -c foo.s -o foo-r2.o > $ mips-linux-gnu-gcc -march=mips32r6 -c foo.s -o foo-r6.o > $ mips-linux-gnu-gcc -march=mips32r2 -r foo-r2.o -o foo-r2-r.o > $ mips-linux-gnu-gcc -march=mips32r6 -r foo-r6.o -o foo-r6-r.o > $ file foo*.o > foo-r2-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped > foo-r2.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped > foo-r6-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped > foo-r6.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped > $ mips-linux-gnu-ld --version > GNU ld (GNU Binutils) 2.39.50.20221112 > [...] > > Maybe it's a recent regression? > > Or is glib trying to make an ELF object out of a non-ELF one, so input > doesn't have correct flags/attributes set? That's not really supported, Yes. That is the problem I try to workaround: GLib try to convert a pure data file to an ELF object. > they need to get at their input data through an assembly source, via the > `.incbin' pseudo-op (invented many years ago to solve this very problem). > I was bitten by this issue decades ago too, even before `.incbin' existed. > Yes. You introduced this option to me, while 1) GLib guys refused this way 2) Few peopel know about. If most of any arch can work, but us, it's MIPS's bug: we cannot change the whole world. > Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 13:00 ` YunQiang Su @ 2023-05-08 14:43 ` Maciej W. Rozycki 2023-05-08 19:06 ` Maciej W. Rozycki 0 siblings, 1 reply; 17+ messages in thread From: Maciej W. Rozycki @ 2023-05-08 14:43 UTC (permalink / raw) To: YunQiang Su Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford On Mon, 8 May 2023, YunQiang Su wrote: > > they need to get at their input data through an assembly source, via the > > `.incbin' pseudo-op (invented many years ago to solve this very problem). > > I was bitten by this issue decades ago too, even before `.incbin' existed. > > > > Yes. You introduced this option to me, while > 1) GLib guys refused this way What can I say? If you find a bug in a piece of software and its authors refuse to fix it, then perhaps they should change industry as they have an attitude problem. I've seen it before, I once reported a crash due to a stack overrun (an access was made beyond the bottom of the stack, which wasn't mapped) in a proprietary binary library we used at my previous job place and the vendor refused to debug and fix it claiming it cannot happen. We stopped working with said vendor. Maintainers of other software packages do not appear to have this problem and accept that they may have made a mistake. I don't remember where I've last seen a piece of software converted to use `.incbin' for portability reasons, but I did see it happen. Also search the Internet for `"objcopy" "incbin"' and see how often the matter pops up. > 2) Few peopel know about. Well, software development is a complex matter and competence is unevenly spread I suppose. We've had this pseudo-op for over 20 years now: <https://sourceware.org/legacy-ml/binutils/2001-06/msg00817.html> and it isn't unique to GAS according to the originator. > If most of any arch can work, but us, it's MIPS's bug: we cannot > change the whole world. It's not a MIPS bug, and I have seen it elsewhere too. For example: <https://lists.gnu.org/archive/html/bug-binutils/2014-01/msg00037.html>. Software maintainers need to accept all the world's not a VAX/x86/whatever and that if something works by chance in the majority of cases, it does not mean it is correct. You're right in that we can't fix all the world though, so if maintainers of a given piece of software cannot be persuaded to accept a valid fix, you can still keep the fix locally or drop the package. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 14:43 ` Maciej W. Rozycki @ 2023-05-08 19:06 ` Maciej W. Rozycki 2023-05-09 3:16 ` YunQiang Su 0 siblings, 1 reply; 17+ messages in thread From: Maciej W. Rozycki @ 2023-05-08 19:06 UTC (permalink / raw) To: YunQiang Su Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford On Mon, 8 May 2023, Maciej W. Rozycki wrote: > > If most of any arch can work, but us, it's MIPS's bug: we cannot > > change the whole world. > > It's not a MIPS bug, and I have seen it elsewhere too. For example: > <https://lists.gnu.org/archive/html/bug-binutils/2014-01/msg00037.html>. > Software maintainers need to accept all the world's not a VAX/x86/whatever > and that if something works by chance in the majority of cases, it does > not mean it is correct. To be fair we might well suppress setting and/or verifying ISA, ASE, PIC, etc. flags for object files that only contain data (i.e. no SHF_EXECINTR sections), because such annotation is only relevant to executable code. This would I suppose largely mitigate the issue with linking object files made from raw data with LD or `objcopy'. Maciej ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 19:06 ` Maciej W. Rozycki @ 2023-05-09 3:16 ` YunQiang Su 2023-05-09 7:58 ` Richard Sandiford 0 siblings, 1 reply; 17+ messages in thread From: YunQiang Su @ 2023-05-09 3:16 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford Let's be back to the problem of this patch: what should we do for mipsisa32rXel-*-as -64 and mipsisa64rXel-*-as -32 We have several options: 1. Keep current, aka issue an error message and exit for 32-64 combination. 2. set the default arch to mips64r6 only for mipsisa32r6, aka not for mipsisa32r[1-5]. set the default arch to mips32r6 only for mipsisa64r6, aka not for mipsisa32r[1-5]. That's what I did in this patch. 3. set the default arch to mips64rN for mipsisa32rN set the default arch to mips32rN for mipsisa64rN but do nothing for any other triples, such as mipstx39* or mips64vr, Since it's hard to determine which arches are best for them. 4. Set the default 32/64 arch for all triples. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-09 3:16 ` YunQiang Su @ 2023-05-09 7:58 ` Richard Sandiford 0 siblings, 0 replies; 17+ messages in thread From: Richard Sandiford @ 2023-05-09 7:58 UTC (permalink / raw) To: YunQiang Su Cc: Maciej W. Rozycki, Jiaxun Yang, YunQiang Su, Binutils, Xi Ruoyao YunQiang Su <syq@debian.org> writes: > Let's be back to the problem of this patch: what should we do for > mipsisa32rXel-*-as -64 > and > mipsisa64rXel-*-as -32 > We have several options: > 1. Keep current, aka issue an error message and exit for 32-64 combination. > 2. set the default arch to mips64r6 only for mipsisa32r6, aka not for > mipsisa32r[1-5]. > set the default arch to mips32r6 only for mipsisa64r6, aka not for > mipsisa32r[1-5]. > That's what I did in this patch. > 3. set the default arch to mips64rN for mipsisa32rN > set the default arch to mips32rN for mipsisa64rN > but do nothing for any other triples, such as > mipstx39* or mips64vr, > Since it's hard to determine which arches are best for them. Personally, I think we should do this one, similarly to your 9171de358f230b64646bbb525a74e5f8e3dbe0dc. IMO it's better to think of mipsr6+ as a separate ISA group from pre-r6, since no pair of ISAs from either group is binary compatible in either direction. So for mipsr6+ toolchains (those with a mipsr6+ triplet), from-abi should select the appropriate r6 ISA rather than mips1 or mips3. Thanks, Richard > 4. Set the default 32/64 arch for all triples. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-07 18:34 ` Jiaxun Yang 2023-05-07 19:01 ` Maciej W. Rozycki @ 2023-05-08 9:18 ` YunQiang Su 2023-05-08 9:39 ` Andreas Schwab 2 siblings, 0 replies; 17+ messages in thread From: YunQiang Su @ 2023-05-08 9:18 UTC (permalink / raw) To: Jiaxun Yang Cc: Maciej W. Rozycki, YunQiang Su, Binutils, Xi Ruoyao, richard.sandiford Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月8日周一 02:35写道: > > > > > 2023年5月7日 19:17,Maciej W. Rozycki <macro@orcam.me.uk> 写道: > > > > On Sat, 6 May 2023, Jiaxun Yang wrote: > > > >>>> Hmm, why people wants to build n32 binary on mips32r6 CPU? > >>> > >>> I guess o32 toolchain should not work only for 32bit CPU? > >> > >> In this case people should override -march option themself, not rely on random > >> toolchain hacks, since it’s not determinant from user’s perspective what “fallback” > >> march it will be, especially in case the toolchain is not designed for base ISA. > > > > Seconded. If anyhow, I'd suggest changing the arrangement the GCC way, > > that is by adding `--with-arch-32=' and `--with-arch-64=' configuration > > options. I'm not terribly convinced however that would be a worthwhile > > improvement, because GAS shouldn't normally be invoked directly, and when > > called via the GCC driver the driver will do the right thing. > > > > YunQiang, do you actually have a use case for invoking GAS directly? I > > only do it when debugging GAS, which is sort of irrelevant. For normal > > compilations I never do it. > > The issue was raised by Glib[1], they are involving `ld` directly. > > I recall v8 was generating embedded data as assembly directives and then invoking as to > generate object file. They claimed it’s faster than GCC. > > I think it make sense to get this “workaround” done in GAS/LD, but not in this way. > `--with-arch-32=' and `--with-arch-64=` method fits the purpose better. > My worry about the --with-arch-32/64 is that: somebody may create a toolchain like this: ../configure --target=mipsisa64r6el-linux-gnu --with-arch-32=mips32 --with-arch-64=mips64r2 > Thanks > Jiaxun > > [1]: https://gitlab.gnome.org/GNOME/glib/-/issues/2768 > > > > Maciej > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-07 18:34 ` Jiaxun Yang 2023-05-07 19:01 ` Maciej W. Rozycki 2023-05-08 9:18 ` YunQiang Su @ 2023-05-08 9:39 ` Andreas Schwab 2023-05-08 10:51 ` YunQiang Su 2 siblings, 1 reply; 17+ messages in thread From: Andreas Schwab @ 2023-05-08 9:39 UTC (permalink / raw) To: Jiaxun Yang via Binutils Cc: Maciej W. Rozycki, Jiaxun Yang, YunQiang Su, YunQiang Su, Xi Ruoyao, richard.sandiford On Mai 07 2023, Jiaxun Yang via Binutils wrote: > The issue was raised by Glib[1], they are involving `ld` directly. Since commit 6d93568e3 they don't appear to do that any more. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit 2023-05-08 9:39 ` Andreas Schwab @ 2023-05-08 10:51 ` YunQiang Su 0 siblings, 0 replies; 17+ messages in thread From: YunQiang Su @ 2023-05-08 10:51 UTC (permalink / raw) To: Andreas Schwab Cc: Jiaxun Yang via Binutils, Maciej W. Rozycki, Jiaxun Yang, YunQiang Su, Xi Ruoyao, richard.sandiford Andreas Schwab via Binutils <binutils@sourceware.org> 于2023年5月8日周一 17:40写道: > > On Mai 07 2023, Jiaxun Yang via Binutils wrote: > > > The issue was raised by Glib[1], they are involving `ld` directly. > > Since commit 6d93568e3 they don't appear to do that any more. > Thanks for your information, and I have a test, it still cannot work with the MIPS case. Maybe MIPS's compiler should pass more options to linker then. Does linker accept an runtime option for ISA level? Let me have a check. > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-05-09 7:58 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-06 8:37 [PATCH] MIPS: gas: alter 64 or 32 for r6 triples if march is implicit YunQiang Su 2023-05-06 8:42 ` Jiaxun Yang 2023-05-06 8:52 ` YunQiang Su 2023-05-06 9:15 ` Jiaxun Yang 2023-05-07 18:17 ` Maciej W. Rozycki 2023-05-07 18:34 ` Jiaxun Yang 2023-05-07 19:01 ` Maciej W. Rozycki 2023-05-08 9:16 ` YunQiang Su 2023-05-08 12:25 ` Maciej W. Rozycki 2023-05-08 13:00 ` YunQiang Su 2023-05-08 14:43 ` Maciej W. Rozycki 2023-05-08 19:06 ` Maciej W. Rozycki 2023-05-09 3:16 ` YunQiang Su 2023-05-09 7:58 ` Richard Sandiford 2023-05-08 9:18 ` YunQiang Su 2023-05-08 9:39 ` Andreas Schwab 2023-05-08 10:51 ` YunQiang Su
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).