Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel

Message ID 20240620024324.18568-1-syq@gcc.gnu.org
State New
Headers
Series Build: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_gcc_check--master-arm success Test passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 success Test passed

Commit Message

YunQiang Su June 20, 2024, 2:43 a.m. UTC
  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(+)
  

Comments

Richard Sandiford June 21, 2024, 9:18 a.m. UTC | #1
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 \
  
Maciej W. Rozycki June 21, 2024, 12:55 p.m. UTC | #2
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
  
Maciej W. Rozycki June 21, 2024, 2 p.m. UTC | #3
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
  
YunQiang Su June 21, 2024, 2:03 p.m. UTC | #4
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
  
YunQiang Su June 21, 2024, 2:06 p.m. UTC | #5
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
  
YunQiang Su June 21, 2024, 2:10 p.m. UTC | #6
> >
> >  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.
  

Patch

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 \