This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]