This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/mips] Second go at vr5500 hilo hazard fix
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: cgd at broadcom dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 18 Mar 2004 20:55:56 +0000
- Subject: Re: [rfa/mips] Second go at vr5500 hilo hazard fix
- References: <87oequw5xw.fsf@redhat.com> <mailpost.1079622402.27828@news-sj1-1><yov5wu5ivy1n.fsf@ldt-sj3-010.sj.broadcom.com>
cgd@broadcom.com writes:
> Now that the mips sim 'multi' bits are in place (including good
> default), and we have MIPS_MACH(SD) (thanks! 8-), it should be
> possible to code a simple macro which checks for the appropriate bfd
> machine, and decides whether interlocks are present.
Well, I had a similar check in:
http://sources.redhat.com/ml/gdb-patches/2002-11/msg00642.html
OK, so it wasn't wrapped up in a nice macro, it just checked the
architecture directly:
+ /* There are no timing requirements in vr5500 code. */
+ if (MIPS_MACH (SD) == bfd_mach_mips5500)
+ return 1;
But that was exactly what Andrew objected to:
http://sources.redhat.com/ml/gdb-patches/2002-11/msg00668.html
Then there was:
http://sources.redhat.com/ml/gdb-patches/2002-12/msg00080.html
To quote:
As for having to tag each individual entry in the .igen file with an
explicit CPU. Yes, that sux. However, I also believe that it has
significantly reduced the overall error rate (no more breaking one
target by editing another) and that benefit vastly outweighs the short
term pain.
Richard