[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: gdbserver on sh4
From:       Michael Trimarchi <trimarchi () gandalf ! sssup ! it>
Date:       2009-03-31 9:08:25
Message-ID: 49D1DD89.1050006 () gandalf ! sssup ! it
[Download RAW message or body]

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.

Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

[prev in list] [next in list] [prev in thread] [next in thread]