This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, Mar 31, 2009 at 11:02:38AM +0200, Michael Trimarchi wrote:Ok, I will try to provide a new patch to move out the dsp save/restore part from the
Paul Mundt wrote:
On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:I just send a patch that put the dsp state in the thread struct
The problem is kernel side and not gdb side. I send a patch to theThe sanest thing really is just to throw the DSP state in to the thread
linux-sh mailing list. They save the dsp register on the stack before
the processor cpu register but the offset of the struct is wrong
calculated and if the linux kernel is compiled with the dsp option
the PEEKUSR return the wrong register value.
struct as we do with the FPU, and kill off all of the special DSP state
handling we have today. It costs us a thread flag to do lazy context
You sent a patch that cached the enable/disable state in the thread
struct, not the register state. ;-)
switching, but it's worth it to get that crap out of the regular registerSo move the save/restore part of the dsp in private data of task and do like
save/restore paths, which is just way too fragile, and has not seen any
real maintenance since SH3-DSP.
mips?
Yes.
-- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |