This is the mail archive of the
mailing list for the GDB project.
Re: [rfa/mips] Second go at vr5500 hilo hazard fix
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
I still take issue with the latter ("short term pain"), for such
additions have to stay in for the life of support for the arch in the
simulator, which *should* be quite long term.
Look at it this way, if the igen mechanism is used, gcc is able to
eliminate everything :-)
If there's another way of achieving the same effect, I'm interested.
But that was exactly what Andrew objected to:
And he and I (strongly, IMO) disagreed at that time. (IIRC, I think I
mentioned at the time that the right solution to this is better
testing. I still think that's true.)
Of course, in August of last year, (unprompted by me!) he decided to
stop being MIPS co-maintainer. So, at this point, I'm the approval
authority, and I like my style of patch most. 8-)
I would like to see it augmented to include some test code (now that
there's a prelim test framework for mips, with what, 1 test? 8-), but
as long as you commit to actually doing that I'm OK with it waiting a