From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22359 invoked by alias); 19 Jun 2009 16:05:43 -0000 Received: (qmail 21982 invoked by uid 22791); 19 Jun 2009 16:05:41 -0000 X-SWARE-Spam-Status: No, hits=-1.2 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:05:31 +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 1MHhOA-0005Hz-Gk; Fri, 19 Jun 2009 18:56:30 +0200 Message-ID: <4A3BB676.2090907@evidence.eu.com> Date: Fri, 19 Jun 2009 16:05:00 -0000 From: michael User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "damien.courousse.logica" 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> In-Reply-To: <24114181.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00190.txt.bz2 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