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

List:       gdb
Subject:    Re: gdbserver on sh4
From:       michael <michael () evidence ! eu ! com>
Date:       2009-06-19 16:16:33
Message-ID: 4A3BB9E1.1010604 () evidence ! eu ! com
[Download RAW message or body]

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


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