Saving/restoring MIPS t-registers on 32-bit systems

Saving/restoring MIPS t-registers on 32-bit systems

[David VomLehn]

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@cisco.com>

Re: Saving/restoring MIPS t-registers on 32-bit systems

[David Daney]

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@cisco.com>
> 

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

Re: Saving/restoring MIPS t-registers on 32-bit systems

[David VomLehn]

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@cisco.com>
>>
>
> 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

Re: Saving/restoring MIPS t-registers on 32-bit systems

[David Daney]

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@cisco.com>
>>>
>> 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