This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Does -march=r5000 imply HAVE_64BIT_GPRS?
- To: binutils at sourceware dot cygnus dot com
- Subject: Re: Does -march=r5000 imply HAVE_64BIT_GPRS?
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Date: Sat, 18 Aug 2001 00:53:59 +0200
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