> I Am Dumb. Check CVS history, but I think I changed that just a > couple of weeks ago; I audited all the sniffers looking for what ought > to use the unwound PC and what ought to use the unwound block address. > Here, I'm pretty sure I made the wrong choice. Yep, I remembered. However, I also thought that your choice made sense. I really think it does, but given: > I would recommend you revert my changes to this function and > mips_insn32_frame_sniffer instead. And: > > It seems to me that the above check is only an optimization, > > and I've spotted at least one instance where I cannot see an > > obvious guaranty that the address has not been decremented > > by one of the _in_block functions... So the decision I made > > was to remove that check. > > No, it's not just an optimization. Especially with limited debug > info, it's important. ^^^^^^^^^^^^^^ I decided to revert your changes for now. > > 2. One minor: There was a confusion in the unwinder between > > the return address and the address of the instruction calling us. > > So I replaced frame_pc_unwind calls by their associated > > frame_unwind_address_in_block. > > This half looks right. Thanks. So here is what I ended up checkin in: 2007-03-07 Joel Brobecker * mips-tdep.c (mips_insn16_frame_cache, mips_insn32_frame_sniffer): Revert the previous change that had some unexpected side-effects on mips32. (mips_insn16_frame_cache, mips_insn32_frame_cache): Use the proper function to get the address of the calling instruction. Re-tested on mips-irix, just to be sure. Same results as before (meaning about 500 less FAILs). I'm also sad to report that I have been told to put off work on mips-irix for a while. That was a personal initiative on my side, but I'm lacking time at work, so this was the first task that got cut. I hope someone else can find the time to bring it back to life... Thanks again, Daniel. -- Joel