Maciej W. Rozycki <ma...@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
