Re: gdbserver on sh4

[michael <michael@evidence.eu.com>]

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