From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2736 invoked by alias); 19 Jun 2009 15:56:49 -0000 Received: (qmail 2727 invoked by uid 22791); 19 Jun 2009 15:56:48 -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 15:56:38 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MHgSC-0006Fr-If for gdb@sourceware.org; Fri, 19 Jun 2009 08:56:36 -0700 Message-ID: <24114181.post@talk.nabble.com> Date: Fri, 19 Jun 2009 15:56:00 -0000 From: "damien.courousse.logica" To: gdb@sourceware.org Subject: Re: gdbserver on sh4 In-Reply-To: <49D1DD89.1050006@gandalf.sssup.it> 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> 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/msg00189.txt.bz2 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.