This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb support for Atmel AVR
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: "Theodore A. Roth" <troth at verinet dot com>
- Cc: gdb at sources dot redhat dot com, Jim blandy <jimb at redhat dot com>
- Date: Fri, 08 Feb 2002 11:33:00 -0500
- Subject: Re: gdb support for Atmel AVR
- References: <Pine.LNX.4.44.0202071240120.11375-100000@bozoland.mynet>
> Hi,
>
> I have a patch for gdb-5.1 which adds support for Atmel's AVR
> microprocessors. It's getting to the point where it works well and is
> closing in on being ready for submission for inclusion.
Nice. Are the specs online somewhere? Be interesting to look at this
beast.
Is there a simulator as well?
> Before the patch can be considered for inclusion, I know I need to sign
> some documents. Thus, can someone point me at them? I've searched the web
> and have only found references to the them, but not the actual docs. I
> would also need to know where to send the signed docs.
>
> I was also wondering if someone would be kind enough to review the patch
> as it stands now and comment on it. I'm sure it will need some more work
> to clean up loose ends before it can be accepted for inclusion. It might
> need broken up since it's a rather large patch right now.
>
> Here's a link to the patch:
> http://freesoftware.fsf.org/download/simulavr/gdb-patches/
>
(Expect an e-mail from GDB assignment's clerk with the assignment info
you need).
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.
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.
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).
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.
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.
enjoy,
Andrew
(1) Things to do today is add a gdb_style.sh.