Re: gdb support for Atmel AVR

[Andrew Cagney <ac131313@cygnus.com>]

> 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.