On Wed, Apr 29, 2009 at 01:47:27PM -0700, David Daney wrote: > David VomLehn wrote: >> Which MIPS processor t-registers (t0-t9) does gcc save and restore on 32-bit >> builds? I have a case where it looks like a function alters those and they >> are not getting restored after the call. I don't have a clean test case, but >> wanted to check whether this is known behavior. This is quite an old version >> of gcc, 3.4.4 >> -- >> David VomLehn <dvomlehn@xxxxxxxxx> >> > > None of them, they are temporary registers. They can all be clobbered > by a function call. As you know t9 ($25) is used for indirect function > calls in o32, n32, n64 (and perhaps others as well) ABIs. > David Daney Sorry, I wrote that first message much too quickly. Let me try again: We're re-writing the MIPS kernel version of memcpy and when we use $at, t5, t6, or t9, Bad Things happen. We don't seem to have any problem with using t0-t4 and t7, but I have no idea why those registers should be any "safer" than the others. I expect that use of t5, t6, and t9 is very rare, and $at is used only during very brief windows, so there are two possibilities that I can see: 1. A kernel bug in saving some register subset in exception handling 2. A compiler bug that is not invaliding some t-registers in a function call Both possibilities seem remote, but anything else (like an assembler bug that generates incorrect code that objdump disassembles back to the expected result) seems even more remote. All I can say now is that there is *some* assumption we're making that is incorrect; any help in pointing out which assumption would be greatly appreciated. David VomLehn
