gdbserver on sh4
michael
michael@evidence.eu.com
Fri Jun 19 16:05:00 GMT 2009
damien.courousse.logica wrote:
> Hello all,
>
>
> Hi,
>
> Paul Mundt wrote:
>
>> On Tue, Mar 31, 2009 at 11:02:38AM +0200, Michael Trimarchi wrote:
>>
>>
>>> Paul Mundt wrote:
>>>
>>>
>>>> On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
>>>>
>>>>
>>>>> The problem is kernel 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 is compiled with the dsp option
>>>>> the PEEKUSR return the wrong register value.
>>>>>
>>>>>
>>>>>
>>>> The sanest thing really is just to throw the DSP state in to the thread
>>>> 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
>>>>
>>>>
>>>>
>>> I just send a patch that put the dsp state in the thread struct
>>>
>>>
>> 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
>>>> 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
>>> mips?
>>>
>>>
>> Yes.
>>
>>
> Ok, I will try to provide a new patch to move out the dsp save/restore
> part from the
> stack and move all on the thread privata data.
>
>
>
> I am currently facing the same problem that is described in this thread,
> also on sh4.
> Michael did you provide a kernel patch to fix this? If possible, how could I
> help you?
>
Hi, I just move the dsp register over the stack and I try it. What
kernel version do you use?
Michael
More information about the Gdb
mailing list