[PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[YunQiang Su]

We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel
only, while gcc_cv_as_mips_explicit_relocs is used by later code.

Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
as it has been in Binutils for more than 20 years.

gcc
	* configure.ac: Set gcc_cv_as_mips_explicit_relocs if
	gcc_cv_as_mips_explicit_relocs_pcrel.
	* configure: Regenerate.
---
 gcc/configure    | 2 ++
 gcc/configure.ac | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/gcc/configure b/gcc/configure
index 9dc0b65dfaa..ad998105da3 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30278,6 +30278,8 @@ $as_echo "#define MIPS_EXPLICIT_RELOCS MIPS_EXPLICIT_RELOCS_BASE" >>confdefs.h
 
 fi
 
+    else
+      gcc_cv_as_mips_explicit_relocs=yes
     fi
 
     if test x$gcc_cv_as_mips_explicit_relocs = xno; then \
diff --git a/gcc/configure.ac b/gcc/configure.ac
index b2243e9954a..c51d3ca5f1b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5255,6 +5255,8 @@ LCF0:
 [	lw $4,%gp_rel(foo)($4)],,
       [AC_DEFINE(MIPS_EXPLICIT_RELOCS, MIPS_EXPLICIT_RELOCS_BASE,
 		 [Define if assembler supports %reloc.])])
+    else
+      gcc_cv_as_mips_explicit_relocs=yes
     fi
 
     if test x$gcc_cv_as_mips_explicit_relocs = xno; then \
-- 
2.39.3 (Apple Git-146)

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[Richard Sandiford]

YunQiang Su <syq@gcc.gnu.org> writes:
> We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel
> only, while gcc_cv_as_mips_explicit_relocs is used by later code.
>
> Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> as it has been in Binutils for more than 20 years.

Yeah, agreed FWIW.  This was necessary while the feature was relatively
new, and while we still supported IRIX as, but I can't see any reasonable
justification for using such an ancient binutils with modern GCC.

Getting rid of -mno-explicit-relocs altogether might simplify things.

ichard

>
> gcc
> 	* configure.ac: Set gcc_cv_as_mips_explicit_relocs if
> 	gcc_cv_as_mips_explicit_relocs_pcrel.
> 	* configure: Regenerate.
> ---
>  gcc/configure    | 2 ++
>  gcc/configure.ac | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/gcc/configure b/gcc/configure
> index 9dc0b65dfaa..ad998105da3 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -30278,6 +30278,8 @@ $as_echo "#define MIPS_EXPLICIT_RELOCS MIPS_EXPLICIT_RELOCS_BASE" >>confdefs.h
>  
>  fi
>  
> +    else
> +      gcc_cv_as_mips_explicit_relocs=yes
>      fi
>  
>      if test x$gcc_cv_as_mips_explicit_relocs = xno; then \
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index b2243e9954a..c51d3ca5f1b 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -5255,6 +5255,8 @@ LCF0:
>  [	lw $4,%gp_rel(foo)($4)],,
>        [AC_DEFINE(MIPS_EXPLICIT_RELOCS, MIPS_EXPLICIT_RELOCS_BASE,
>  		 [Define if assembler supports %reloc.])])
> +    else
> +      gcc_cv_as_mips_explicit_relocs=yes
>      fi
>  
>      if test x$gcc_cv_as_mips_explicit_relocs = xno; then \

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[Maciej W. Rozycki]

On Fri, 21 Jun 2024, Richard Sandiford wrote:

> > We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel
> > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> >
> > Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> > as it has been in Binutils for more than 20 years.
> 
> Yeah, agreed FWIW.  This was necessary while the feature was relatively
> new, and while we still supported IRIX as, but I can't see any reasonable
> justification for using such an ancient binutils with modern GCC.
> 
> Getting rid of -mno-explicit-relocs altogether might simplify things.

 FWIW I tend to agree too, although I think the current mess has to be 
fixed first (and backported to the release branches) before going forward 
with the removal.

 And AFAICT the proposed change is the wrong one: it has to be analysed 
how we came at the current breakage and then the state reproducing how it 
used to work before recreated.

 Perhaps we need to check for general explicit reloc support first, before 
following with PC-relative relocs.  It seems natural to me this way, 
because you can't have support for PC-relative relocs (narrower scope) 
unless you have general explicit reloc support (wider scope) in the first 
place, so I wonder why we came up with what we have now.

  Maciej

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[Maciej W. Rozycki]

On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:

> > Yeah, agreed FWIW.  This was necessary while the feature was relatively
> > new, and while we still supported IRIX as, but I can't see any reasonable
> > justification for using such an ancient binutils with modern GCC.
> > 
> > Getting rid of -mno-explicit-relocs altogether might simplify things.
> 
>  FWIW I tend to agree too, although I think the current mess has to be 
> fixed first (and backported to the release branches) before going forward 
> with the removal.

 And FAOD I think a stub check has to remain even after the removal and 
just cause `configure' to bail out if an unsupported obsolete version of 
GAS has been identified.

  Maciej

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2024年6月21日周五 22:00写道：
>
> On Fri, 21 Jun 2024, Maciej W. Rozycki wrote:
>
> > > Yeah, agreed FWIW.  This was necessary while the feature was relatively
> > > new, and while we still supported IRIX as, but I can't see any reasonable
> > > justification for using such an ancient binutils with modern GCC.
> > >
> > > Getting rid of -mno-explicit-relocs altogether might simplify things.
> >
> >  FWIW I tend to agree too, although I think the current mess has to be
> > fixed first (and backported to the release branches) before going forward
> > with the removal.
>
>  And FAOD I think a stub check has to remain even after the removal and
> just cause `configure' to bail out if an unsupported obsolete version of
> GAS has been identified.
>

Sure. And it is also useful to emit error if we cannot find mips binutils.
In fact, sometimes, I meet a problem if I forget to install mips binutils first.

>   Maciej

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[YunQiang Su]

> >
> >  And FAOD I think a stub check has to remain even after the removal and
> > just cause `configure' to bail out if an unsupported obsolete version of
> > GAS has been identified.
> >

Ohh,  I think that we shouldn't remove it now, as I have figure out
the PCREL patch,
and I am still waiting your response of PCREL support of Binutils.

My plan is, once Binutils is ready, I can submit my GCC patch.
I don't want to rewrite them.

And then, we can remove all no_explicit_relocs support. I mean that I
plan to remove
all `TARGET_EXPLICIT_RELOCS` macro related code in mips.cc/mips.h/mips.md etc.

Re: [PATCH] Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

[YunQiang Su]

Maciej W. Rozycki <macro@orcam.me.uk> 于2024年6月21日周五 20:55写道：
>
> On Fri, 21 Jun 2024, Richard Sandiford wrote:
>
> > > We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel
> > > only, while gcc_cv_as_mips_explicit_relocs is used by later code.
> > >
> > > Maybe, it is time for use to set gcc_cv_as_mips_explicit_relocs always now,
> > > as it has been in Binutils for more than 20 years.
> >
> > Yeah, agreed FWIW.  This was necessary while the feature was relatively
> > new, and while we still supported IRIX as, but I can't see any reasonable
> > justification for using such an ancient binutils with modern GCC.
> >
> > Getting rid of -mno-explicit-relocs altogether might simplify things.
>
>  FWIW I tend to agree too, although I think the current mess has to be
> fixed first (and backported to the release branches) before going forward
> with the removal.
>

Sure.

>  And AFAICT the proposed change is the wrong one: it has to be analysed
> how we came at the current breakage and then the state reproducing how it
> used to work before recreated.
>
>  Perhaps we need to check for general explicit reloc support first, before
> following with PC-relative relocs.  It seems natural to me this way,
> because you can't have support for PC-relative relocs (narrower scope)
> unless you have general explicit reloc support (wider scope) in the first
> place, so I wonder why we came up with what we have now.
>

I guess that we can suppose that these stages (some-future-one/pcrel/base)
are a strict superset one by one.

So we can detect the newest one, if it is OK, all older ones are also available.
If we check the oldest one first, we will have some trouble with AC_DEFINE,
as we may emit multiple "#define MIPS_EXPLICIT_RELOCS".

>   Maciej