Re: gdbserver on sh4

["damien.courousse.logica" <damien.courousse@logica.com>]

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?

Damien
-- 
View this message in context: http://www.nabble.com/gdbserver-on-sh4-tp22494576p24114181.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.