gdbserver on sh4

michael michael@evidence.eu.com
Fri Jun 19 16:20:00 GMT 2009


Hi,

Courousse, Damien wrote:
>   
>> -----Message d'origine-----
>> De : michael [mailto:michael@evidence.eu.com]
>> Envoyé : vendredi 19 juin 2009 18:02
>> À : Courousse, Damien
>> Cc : gdb@sourceware.org
>> Objet : Re: gdbserver on sh4
>>
>> 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
>>     
> Hi Michael,
>
> I use a kernel source tree modified by STmicroelectronics : linux-sh4-STAPI_2.6.23.17_stm23_A16 - it is based on the kernel 2.6.23.
>   
The manteiner has applied the patch to the current linux git. Now you 
can try to apply to your
branch.

Michael



More information about the Gdb mailing list