This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdbserver on sh4
- From: "damien.courousse.logica" <damien dot courousse at logica dot com>
- To: gdb at sourceware dot org
- Date: Fri, 19 Jun 2009 09:14:15 -0700 (PDT)
- Subject: Re: gdbserver on sh4
- References: <49BA416E.6090901@evidence.eu.com> <49BB6311.30805@evidence.eu.com> <22798755.post@talk.nabble.com> <49D1D2F6.1000206@gandalf.sssup.it> <20090331085207.GC31415@linux-sh.org> <49D1DC2E.2060105@gandalf.sssup.it> <20090331090300.GA1977@linux-sh.org> <49D1DD89.1050006@gandalf.sssup.it> <24114181.post@talk.nabble.com> <4A3BB676.2090907@evidence.eu.com>
Michael Trimarchi-3 wrote:
>
> 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.
Damien
--
View this message in context: http://www.nabble.com/gdbserver-on-sh4-tp22494576p24114590.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.