David VomLehn wrote:
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.
It sounds like something weird. I assume you look at a disassembly of
the code to verify that at is not getting clobbered.
You could checkout arch/mips/cavium-octeon/octeon-memcpy.S as an example
of memcpy.
David Daney
