From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21188 invoked by alias); 8 Feb 2002 17:53:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21120 invoked from network); 8 Feb 2002 17:53:05 -0000 Received: from unknown (HELO pasiphae01.frii.com) (216.17.128.33) by sources.redhat.com with SMTP; 8 Feb 2002 17:53:05 -0000 Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by pasiphae01.frii.com (8.12.2/8.12.2) with ESMTP id g18HqwbZ004055; Fri, 8 Feb 2002 10:52:58 -0700 (MST) Received: from ari-co2c-01.rasserver.net (ari-co2c-01.rasserver.net [207.92.201.1]) by deimos.frii.net (8.12.2/8.12.2) with ESMTP id g18HqoEk003667; Fri, 8 Feb 2002 10:52:56 -0700 (MST) Date: Fri, 08 Feb 2002 09:53:00 -0000 From: "Theodore A. Roth" X-X-Sender: troth@bozoland.mynet To: Andrew Cagney cc: gdb@sources.redhat.com, Jim blandy Subject: Re: gdb support for Atmel AVR In-Reply-To: <3C63FDBC.7020708@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-02/txt/msg00143.txt.bz2 On Fri, 8 Feb 2002, Andrew Cagney wrote: :)Nice. Are the specs online somewhere? Be interesting to look at this :)beast. The patch is available here (latest is pre9): :) :)Is there a simulator as well? I'm also writing a simulator which can be used standalone or with gdb as a remote target. There's still a lot of work to be done on it, but it has been very useful in getting avr-gdb working. There's another project using Atmel's JTAG ICE box as a remote target with the same patch. :)(Expect an e-mail from GDB assignment's clerk with the assignment info :)you need). Thanks. :) :)To make the process easier, below is a brief checklist of the things I :)look for in reviewing a target: :) :)The first is multi-arch. Have a look at xstormy16. Old targets are :)being converted to multi-arch and new targets should be multi-arched :)from day one (well at least as far as possible - shlibs are not yet :)finished). Pragmatics: multi-arch makes it much easier for developers :)to work on GDB. It uses multi-arch already. :) :)Next is GNU's coding style and indentation. Here, the best I can :)suggest, is run your code through the gdb_indent.sh script. Pragmatics: :) it is objective. I'm using emacs with gnu C indentation style, so that should be good. :) :)After that is the ARI. Check http://sources.redhat.com/gdb/ari/ and :)have a look at the items listed under Regressions, Errors and Deprecated :)(als glance through the Warnings for things that are comming down the :)pipeline and might also raise an eyebrow). Just remember that the ARI :)is a moving target (more things get deleted all the time) so no one :)expects things to be right from day one. You'll just need to check for :)problems once the code is in. Pragmatics: the intention is to stop the :)code (unintentionally) getting worse. Eg: people adding new references :)to registers[] when we're trying to eliminate all the existing ones (1). I'll take a look at that site. :) :)Finally, there is -Werror. Your target should be buildable with: :) --target= --enable-gdb-build-warnings=,-Werror :)and then start. You need to select your host carefully. Pragmatics: :)anyone making changes across GDB should try rebuilding and running all :)targets. -Werror makes this much easier. That should be easy to do. :) :)The one thing you'll notice isn't on the check list is test results. On :)that count, far as I'm conceerned, as soon as your target is showing :)reasonable signs of life it is ready for acceptance. Some people are already using it for real work so I think it's got a heart beat already. ;) I'm especially interested in someone reviewing the changes I had to make outside of avr-tdep.c and config/avr/*. These changes may affect other targets. I've tried really hard to keep those changes to a minimum though. Ted Roth