From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4057 invoked by alias); 15 Jun 2007 19:05:34 -0000 Received: (qmail 4048 invoked by uid 22791); 15 Jun 2007 19:05:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Jun 2007 19:05:30 +0000 Received: (qmail 26815 invoked from network); 15 Jun 2007 19:05:28 -0000 Received: from unknown (HELO h38.net64.aknet.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jun 2007 19:05:28 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: ColdFire/fido support Date: Fri, 15 Jun 2007 19:05:00 -0000 User-Agent: KMail/1.9.1 Cc: Andreas Schwab , gdb-patches@sources.redhat.com, Eli Zaretskii References: <200705051337.02114.vladimir@codesourcery.com> <200706151417.25052.vladimir@codesourcery.com> <20070615144758.GA10833@caradoc.them.org> In-Reply-To: <20070615144758.GA10833@caradoc.them.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_1LucG3fcs+rPzoU" Message-Id: <200706152305.25699.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00298.txt.bz2 --Boundary-00=_1LucG3fcs+rPzoU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 1298 On Friday 15 June 2007 18:47, Daniel Jacobowitz wrote: > On Fri, Jun 15, 2007 at 02:17:24PM +0400, Vladimir Prus wrote: > > On Tuesday 12 June 2007 17:38, Daniel Jacobowitz wrote: > > > > > > I suppose I can add file-based detection for fido, just like it's done for coldfire, > > > > but I don't think removing XML-based detection is right. What do you think? > > > > > > Right, sorry - I know what I meant to say, but I didn't say it. > > > > > > Float return behavior is not a property of the target at all; it's a > > > property of the compiler options used. decr_pc_after_break is a > > > target property, though, so we should trust the target. This isn't > > > important, though, so feel free to commit without changing this. If > > > it causes any problems we can clean it up later. > > > > Ok, excellent. > > > > I attach a patch that differs only by non-taking of address of builtin_types. OK? > > I also wrote: > > > This is mostly OK. Please add a Makefile.in update for the new > > #include. Also, we've added XML support for another target. So it > > needs a new section in the manual describing which targets support > > XML registers, and which registers are required. > > It does still need those. Other than that it's OK. Does this doco patch look good? - Volodya --Boundary-00=_1LucG3fcs+rPzoU Content-Type: text/x-diff; charset="iso-8859-1"; name="docs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="docs.diff" Content-length: 953 --- gdb.texinfo (revision 4281) +++ gdb.texinfo (local) @@ -25751,6 +25751,22 @@ it should contain at least registers @sa @samp{wCGR0} through @samp{wCGR3}. The @samp{wCID}, @samp{wCon}, @samp{wCSSF}, and @samp{wCASF} registers are optional. +@subsection M68K Features +@cindex target descriptions, M68K features + +An M68K target is required to have either the +@samp{org.gnu.gdb.m68k.core} feature or the +@samp{org.gnu.gdb.coldfire.core} feature or the +@samp{org.gnu.gdb.fido.core} feature. Which feature is present +determines which flavour of m68k is used. The present feature +should contain registers @samp{d0} through @samp{d7}, +@samp{a0} through @samp{a5}, @samp{fp}, @samp{sp}, @samp{ps} and +@samp{pc}. + +The @samp{org.gnu.gdb.coldfire.fp} feature is optional. If present, it +should contain registers @samp{fp0} through @samp{fp7}, +@samp{fpcontrol}, @samp{fpstatus} and @samp{fpiaddr}. + @include gpl.texi @raisesections --Boundary-00=_1LucG3fcs+rPzoU--