This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb support for Atmel AVR
- From: "Theodore A. Roth" <troth at verinet dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb at sources dot redhat dot com, Jim blandy <jimb at redhat dot com>
- Date: Fri, 8 Feb 2002 10:59:58 -0700 (MST)
- Subject: Re: gdb support for Atmel AVR
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):
<http://freesoftware.fsf.org/download/simulavr/gdb-patches/>
:)
:)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.
<http://savannah.gnu.org/projects/simulavr/>
There's another project using Atmel's JTAG ICE box as a remote target with
the same patch.
<http://avarice.sourceforge.net/>
:)(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=<your-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