On 01/04/11 09:54, Anoop P A wrote:
On Tue, 2011-01-04 at 09:21 -0800, Kevin D. Kissell wrote:
I'm trying to figure out a reason why your change below should help, and
offhand, modulo tool bugs, I don't see it. I'm assuming that your diff
below is a diff relative to the pre-patch stackframe.h. I wouldn't
Yes patch created against stock code .
bless it as an alternative because it moves code and comments
unnecessarily - all you should really have to do is to move the
190 mfc0 v1, CP0_STATUS
191 LONG_S $2, PT_R2(sp)
to be just after the #endif /* CONFIG_MIPS_MT_SMTC */ at around line 201.
Actually I just moved code under CONFIG_MIPS_MT_SMTC to previous block
of code ( which store $0 ) . git diff did the rest on behalf of me :)
If moving the save of zero to PT_R0(sp) actually makes a difference,
it's evidence that you've got problems in your toolchain (or, heaven
forbid, your pipeline)!
In previous version of patch usage of V0 was creating issue. I have
verified this with previous version of code ( working code before
David's instruction rearrangement patch.) .
Argh. It's not very clearly commented, but it looks as if the system
call trap handler has an implicit assumption that v0 has never been
changed by SAVE_SOME, TRACE_IRQS_ON_RELOAD, or STI. So yeah, moving the
code around to fix the v1 conflict ends up being better than using v0 -
otherwise, we'd need to add a LONG_L v0, PT_R2(sp) somewhere after the
LONG_S v0, PT_TCSTATUS(sp) of the original patch.
Regards,
Kevin K.
