From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4764 invoked by alias); 19 Jun 2009 16:20:17 -0000 Received: (qmail 4741 invoked by uid 22791); 19 Jun 2009 16:20:12 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from static-88-194-224-77.ipcom.comunitel.net (HELO panicking.kicks-ass.org) (77.224.194.88) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 16:20:06 +0000 Received: from michael.panicking ([192.168.0.192] ident=michael) by panicking.kicks-ass.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MHhcH-0005Id-Fb; Fri, 19 Jun 2009 19:11:05 +0200 Message-ID: <4A3BB9E1.1010604@evidence.eu.com> Date: Fri, 19 Jun 2009 16:20:00 -0000 From: michael User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "Courousse, Damien" CC: gdb@sourceware.org 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00193.txt.bz2 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