From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21820 invoked by alias); 31 Mar 2009 09:07:40 -0000 Received: (qmail 21454 invoked by uid 22791); 31 Mar 2009 09:07:39 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-Spam-Check-By: sourceware.org Received: from 124x34x33x190.ap124.ftth.ucom.ne.jp (HELO master.linux-sh.org) (124.34.33.190) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Mar 2009 09:07:34 +0000 Received: from localhost (unknown [127.0.0.1]) by master.linux-sh.org (Postfix) with ESMTP id D6CFA63765; Tue, 31 Mar 2009 09:03:00 +0000 (UTC) Received: from master.linux-sh.org ([127.0.0.1]) by localhost (master.linux-sh.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGS1+vst-u3m; Tue, 31 Mar 2009 18:03:00 +0900 (JST) Received: by master.linux-sh.org (Postfix, from userid 500) id 90FB563773; Tue, 31 Mar 2009 18:03:00 +0900 (JST) Date: Tue, 31 Mar 2009 09:07:00 -0000 From: Paul Mundt To: Michael Trimarchi Cc: binom , gdb@sourceware.org, linux-sh@vger.kernel.org Subject: Re: gdbserver on sh4 Message-ID: <20090331090300.GA1977@linux-sh.org> Mail-Followup-To: Paul Mundt , Michael Trimarchi , binom , gdb@sourceware.org, linux-sh@vger.kernel.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D1DC2E.2060105@gandalf.sssup.it> User-Agent: Mutt/1.5.13 (2006-08-11) 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-03/txt/msg00192.txt.bz2 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.