gdbserver on sh4

gdbserver on sh4

[michael]

Hi all,

I crosscompile the gdb server for sh and I have trouble to debug a 
simple application,
using it.

I try with the gdb-6.8

./configure --target=sh4-linux

gdbserver
sh3-linux-gcc is a nptl toolchain

CC=sh3-linux-gcc ./configure --host=sh4-linux

server side

./gdbserver-6.8  192.168.10.156:1234 ./foobar_sample                       
Process ./foobar_sample created; pid = 
817                                     
Listening on port 
1234                                                         
Remote debugging from host 192.168.8.242

client side
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu 
--target=sh-linux"...
(gdb) target remote 192.168.10.156:1234
Remote debugging using 192.168.10.156:1234
[New Thread 817]
Got object file from memory but can't read symbols: File format not 
recognized.
0x00000000 in ?? ()

This is how the toolchain is configured
sh3-linux-gcc -v
Using built-in specs.
Target: sh3-linux
Configured with: /home/kpit/fsfsrc/v0701/gcc-4.2-20061205/configure 
--host=i686-linux --target=sh3-linux 
--prefix=/usr/share/gnush4-nofpu_linux_v0701-1 --with-cpu=sh4-nofpu 
--with-sysroot=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
--with-local-prefix=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
--disable-nls --enable-threads --enable-symvers=gnu 
--disable-__cxa_atexit --enable-languages=c,c++ --enable-c99 
--enable-long-long --disable-multilib

(gdb) b main
Breakpoint 1 at 0x4003e6: file main.c, line 23.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7b9dedec in ?? ()
(gdb)

Can anybody help to find the problem?

Kind regards
Michael

Re: gdbserver on sh4

[michael]

Hi,

michael wrote:
> Hi all,
>
> I crosscompile the gdb server for sh and I have trouble to debug a 
> simple application,
> using it.
>
> I try with the gdb-6.8
>
> ./configure --target=sh4-linux
>
> gdbserver
> sh3-linux-gcc is a nptl toolchain
>
> CC=sh3-linux-gcc ./configure --host=sh4-linux
>
> server side
>
> ./gdbserver-6.8  192.168.10.156:1234 
> ./foobar_sample                       Process ./foobar_sample created; 
> pid = 817                                     Listening on port 
> 1234                                                         Remote 
> debugging from host 192.168.8.242
>
> client side
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show 
> copying"
> and "show warranty" for details.
> This GDB was configured as "--host=x86_64-unknown-linux-gnu 
> --target=sh-linux"...
> (gdb) target remote 192.168.10.156:1234
> Remote debugging using 192.168.10.156:1234
> [New Thread 817]
> Got object file from memory but can't read symbols: File format not 
> recognized.
> 0x00000000 in ?? ()
>
> This is how the toolchain is configured
> sh3-linux-gcc -v
> Using built-in specs.
> Target: sh3-linux
> Configured with: /home/kpit/fsfsrc/v0701/gcc-4.2-20061205/configure 
> --host=i686-linux --target=sh3-linux 
> --prefix=/usr/share/gnush4-nofpu_linux_v0701-1 --with-cpu=sh4-nofpu 
> --with-sysroot=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
> --with-local-prefix=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
> --disable-nls --enable-threads --enable-symvers=gnu 
> --disable-__cxa_atexit --enable-languages=c,c++ --enable-c99 
> --enable-long-long --disable-multilib
>
> (gdb) b main
> Breakpoint 1 at 0x4003e6: file main.c, line 23.
> (gdb) c
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x7b9dedec in ?? ()
> (gdb)
>
> Can anybody help to find the problem?
>
> Kind regards
> Michael
>
>
>
>
>
>
I fix this problem, is not a gdb server or gdb problem.

Michael

Re: gdbserver on sh4

[binom]

Dear michael ,
In your reply message it's written that "I fix this problem".
Can you pl explain what was the problem and and which is the components to
be updated for incorporating this fix?
Below given is the details of the host side GDB and target side gdbserver.
 sh4-linux-gdb --version
GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
 
 
 
gdbserver --version
GNU gdbserver STMicroelectronics/Linux Base 6.5-15
Copyright (C) 2006 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "sh4-linux"
Thankx,
Bino

Michael Trimarchi-3 wrote:
> 
> Hi,
> 
> michael wrote:
>> Hi all,
>>
>> I crosscompile the gdb server for sh and I have trouble to debug a 
>> simple application,
>> using it.
>>
>> I try with the gdb-6.8
>>
>> ./configure --target=sh4-linux
>>
>> gdbserver
>> sh3-linux-gcc is a nptl toolchain
>>
>> CC=sh3-linux-gcc ./configure --host=sh4-linux
>>
>> server side
>>
>> ./gdbserver-6.8  192.168.10.156:1234 
>> ./foobar_sample                       Process ./foobar_sample created; 
>> pid = 817                                     Listening on port 
>> 1234                                                         Remote 
>> debugging from host 192.168.8.242
>>
>> client side
>> GNU gdb 6.8
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show 
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "--host=x86_64-unknown-linux-gnu 
>> --target=sh-linux"...
>> (gdb) target remote 192.168.10.156:1234
>> Remote debugging using 192.168.10.156:1234
>> [New Thread 817]
>> Got object file from memory but can't read symbols: File format not 
>> recognized.
>> 0x00000000 in ?? ()
>>
>> This is how the toolchain is configured
>> sh3-linux-gcc -v
>> Using built-in specs.
>> Target: sh3-linux
>> Configured with: /home/kpit/fsfsrc/v0701/gcc-4.2-20061205/configure 
>> --host=i686-linux --target=sh3-linux 
>> --prefix=/usr/share/gnush4-nofpu_linux_v0701-1 --with-cpu=sh4-nofpu 
>> --with-sysroot=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
>> --with-local-prefix=/usr/share/gnush4-nofpu_linux_v0701-1/sh3-linux/sys-root 
>> --disable-nls --enable-threads --enable-symvers=gnu 
>> --disable-__cxa_atexit --enable-languages=c,c++ --enable-c99 
>> --enable-long-long --disable-multilib
>>
>> (gdb) b main
>> Breakpoint 1 at 0x4003e6: file main.c, line 23.
>> (gdb) c
>> Continuing.
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x7b9dedec in ?? ()
>> (gdb)
>>
>> Can anybody help to find the problem?
>>
>> Kind regards
>> Michael
>>
>>
>>
>>
>>
>>
> I fix this problem, is not a gdb server or gdb problem.
> 
> Michael
> 
> 

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

Re: gdbserver on sh4

[Michael Trimarchi]

Hi,

binom wrote:
> Dear michael ,
> In your reply message it's written that "I fix this problem".
> Can you pl explain what was the problem and and which is the components to
> be updated for incorporating this fix?
> Below given is the details of the host side GDB and target side gdbserver.
>  sh4-linux-gdb --version
> GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
>   
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.

Michael

Re: gdbserver on sh4

[Paul Mundt]

On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
> binom wrote:
> >Dear michael ,
> >In your reply message it's written that "I fix this problem".
> >Can you pl explain what was the problem and and which is the components to
> >be updated for incorporating this fix?
> >Below given is the details of the host side GDB and target side gdbserver.
> > sh4-linux-gdb --version
> >GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
> >Copyright (C) 2006 Free Software Foundation, Inc.
> >GDB is free software, covered by the GNU General Public License, and you 
> >are
> >welcome to change it and/or distribute copies of it under certain
> >conditions.
> >Type "show copying" to see the conditions.
> >There is absolutely no warranty for GDB.  Type "show warranty" for details.
> >This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
> >  
> 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
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.

Re: gdbserver on sh4

[Michael Trimarchi]

Paul Mundt wrote:
> On Tue, Mar 31, 2009 at 10:23:18AM +0200, Michael Trimarchi wrote:
>   
>> binom wrote:
>>     
>>> Dear michael ,
>>> In your reply message it's written that "I fix this problem".
>>> Can you pl explain what was the problem and and which is the components to
>>> be updated for incorporating this fix?
>>> Below given is the details of the host side GDB and target side gdbserver.
>>> sh4-linux-gdb --version
>>> GNU gdb STMicroelectronics/Linux Base 6.5-33 [build Jul 30 2008]
>>> Copyright (C) 2006 Free Software Foundation, Inc.
>>> GDB is free software, covered by the GNU General Public License, and you 
>>> are
>>> welcome to change it and/or distribute copies of it under certain
>>> conditions.
>>> Type "show copying" to see the conditions.
>>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>>> This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux".
>>>  
>>>       
>> The problem is kernel git clone git://git.openmoko.org/git/kernel.git linux-2.6
>> 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
> 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?
> --
> 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
>
>   
Michael

Re: gdbserver on sh4

[Paul Mundt]

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.

Re: gdbserver on sh4

[Michael Trimarchi]

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
>
>   

Re: gdbserver on sh4

[damien.courousse.logica]

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.

Re: gdbserver on sh4

[michael]

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

Re: gdbserver on sh4

[damien.courousse.logica]

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.

Re: gdbserver on sh4

[michael]

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