1*3de6a9c0SDavid du Colombiergorka writes: 2*3de6a9c0SDavid du Colombier--- 3*3de6a9c0SDavid du ColombierI have userspace on the gumstix [xscale, not omap]. The problem that 4*3de6a9c0SDavid du Colombiergot me in trouble was that in lexception.s (or l.s), 5*3de6a9c0SDavid du Colombier 6*3de6a9c0SDavid du Colombier MOVM.DB.W [R0-R14], (R13) 7*3de6a9c0SDavid du Colombier 8*3de6a9c0SDavid du Colombierworks differently for this architecture (and probably for others, as 9*3de6a9c0SDavid du Colombierit is unclear how it should behave by reading the arm specs). This 10*3de6a9c0SDavid du Colombierhappens only for kernel faults as the others (syscall, user faults) 11*3de6a9c0SDavid du Colombieruse MOVM.DB.W.S which uses the banked user registers. 12*3de6a9c0SDavid du Colombier 13*3de6a9c0SDavid du ColombierThe problem is that in this arch the value of R13 saved is the value 14*3de6a9c0SDavid du Colombierafter R13 itself has been modified, whereas in the others (bitsy, 15*3de6a9c0SDavid du Colombierpico...), it was the value before. Adding 4*15 to the stack before 16*3de6a9c0SDavid du Colombierthe RFE solves the problem. 17*3de6a9c0SDavid du Colombier--- 18*3de6a9c0SDavid du Colombier 19*3de6a9c0SDavid du ColombierIn fact, the 2005 ARM arch. ref. man. (ARM DDI 0100I) says, under STM (1), 20*3de6a9c0SDavid du Colombierthat if Rn appears in the set of registers (and isn't the first one) 21*3de6a9c0SDavid du Colombierand .W is specified, the stored value of Rn is unpredictable. 22*3de6a9c0SDavid du ColombierThe arm v7-ar arch. ref. man. says such usage is obsolete. 23