From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30907 invoked by alias); 19 Jun 2009 16:14:28 -0000 Received: (qmail 30873 invoked by uid 22791); 19 Jun 2009 16:14:22 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from kuber.nabble.com (HELO kuber.nabble.com) (216.139.236.158) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 16:14:17 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MHgjH-0007KL-9K for gdb@sourceware.org; Fri, 19 Jun 2009 09:14:15 -0700 Message-ID: <24114590.post@talk.nabble.com> Date: Fri, 19 Jun 2009 16:14:00 -0000 From: "damien.courousse.logica" To: gdb@sourceware.org Subject: Re: gdbserver on sh4 In-Reply-To: <4A3BB676.2090907@evidence.eu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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> 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/msg00192.txt.bz2 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.