This is the mail archive of the
mailing list for the GDB project.
Re: gdbserver on sh4
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
binom wrote:The sanest thing really is just to throw the DSP state in to the thread
Dear michael ,The problem is kernel git clone git://git.openmoko.org/git/kernel.git linux-2.6
In your reply message it's written that "I fix this problem".
Can you pl explain what was the problem and and which is the components to
be updated for incorporating this fix?
Below given is the details of the host side GDB and target side gdbserver.
GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
side and not gdb side. I send a patch to the 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
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
switching, but it's worth it to get that crap out of the regular register
save/restore paths, which is just way too fragile, and has not seen any
real maintenance since SH3-DSP.
So move the save/restore part of the dsp in private data of task and do like
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html