Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

H . J . Lu wrote:
> On Fri, Aug 17, 2001 at 08:10:27PM +0200, Thiemo Seufer wrote:
> > > 
> > > Only for BFD, not for assembler. Besides, when -mips2 is used with
> > > -march=r5000, the assembler shouldn't use any instructions which are
> > > in r5000, but not in MISP II.
> > 
> > Well, now I can reiterate my question: Why shouldn't it do so?
> > 
> > Of course, in the case of r5000 this makes no difference since it
> > has no insns which aren't covered by an ISA (WRT binutils). An
> > example might be the VR4100: Restrict it to MIPS II but use it's
> > "standby" and "suspend" opcodes. With runtime CPU detection it is
> > easy to find a scenario where this makes sense.
> > 
> 
> There are several problems:

0. Fiddling around with object file header flags in the assembler
is ugly, there should be an adequate bfd interface.

> 1. When -mips2 is passed to as, should anything beyond MIPS II be
> generated? My answer is no.
> 2. Assuming we do allow extra insns beyond MIPS II, what value should
> be in EF_MIPS_ARCH? bfd_set_arch_mach is used to set EF_MIPS_ARCH.

I don't see how bfd_default_set_arch_mach could do this. AFAICS it
sets the machine vector in the bfd, and EF_MIPS_ARCH is set by
_bfd_mips_elf_final_write_processing based on this vector only.

> In my opinion, if we do allow extra insns beyond MIPS II, we should
> add a call to set EF_MIPS_MACH. That should be orthogonal to
> EF_MIPS_ARCH. One way to do it to add
> 
> bfd_mach_mips1
> bfd_mach_mips2
> bfd_mach_mips3
> bfd_mach_mips4
> 
> and we can do
> 
> bfd_set_arch_mach (stdoutput, bfd_arch_mips,
> 		   bfd_mach_mips2 | bfd_mach_mips4100);
>
> We use bfd_mach_mips2 to set EF_MIPS_ARCH and bfd_mach_mips4100 to
> set EF_MIPS_ARCH.

bfd_default_set_arch_mach can't handle more than one mach, and
AFAICS everything assumes to get/store one distinct value via
this interface.

Strangely enough, the ChangeLog says that at 1999-04-15 Gavin Romig-Koch
introduced some code to set EF_MIPS_ARCH in the assembler and reverted
the patch the next day. I haven't found any trace of these in the
mailing list archives.


Thiemo