Adam Seychell wrote: > Hi > > I have joined this list to get help with port 8bit AVR patches > disributed with Atmel's AVR toolchain to the current official GCC, and > binutils. As you may be aware, Atmel have separated development from the > official gcc, binutils and avr-libc projects. I am new making > contributions to FSF and so I am initially interested the procedures > involved. > > I understand to match the full list of devices supported by Atmel's > toolchain requires contributions to all three FSF projects: gcc, > binutils, and avr-libc. Atmel have done most the work by supplying > patches and device header files. However the patches may not be applied > to the development releases of the official projects because the patches > are made for gcc-4.6.2, binutils 2.22 and avr-libc 1.8.0. The Atmel > patches are available from the downloadable toolchain: > > http://www.atmel.com/Images/avr-toolchain-installer-3.4.1.1195-win32.win32.x86.exe > > > I have managed to apply the patches to the official binutils 2.22 and > avr-libc 1.8.0 and successfully build them on my cygwin system. The > gcc-4.6.2 patches from Atmel will not work on current gcc-4.7.2 as the > code structure for device definitions has changed. However I managed to > extract devices information contained in Atmel patches (with help of a > small perl script) and integrate them to gcc 4.7.2. This only involved > modifying two files in gcc-4.7.2 source: > gcc/config/avr-devices.c > gcc/config/avr-mcus.def
Hi Adam, there is also changes needed for -mmcu= documentation as provided in gcc/doc/invoke.texi Moreover, you should try to work against the current development (trunk) and not against a release that is "bug fixes and documentation changes only". In 4.8, parts of the documentation is auto-generated, see gcc/config/avr/gen-avr-mmcu-texi.c gcc/doc/avr-mmcu.texi After integration in trunk you might get approval to backport to the 4.7 branch. The changes are almost trivial because xmega core support is already there, and it's up to the avr port maintainers to allow such changes. However, this requires that the compiler is distributed with future binutils 2.24 which is quite a restriction, so that I think backporting to 4.7 branch is not a good idea. It may be, however, be a good idea to have patches against 4.7 available so that a package maintainer can roll a 4.7 distribution with extended device support without itches. Using a script to extract information might save you some time. My experience is that Atmel patches are not really reliable and need thorough review. It's not the first time I found problems in Atmel's approach. One example is PR52474; an other one is the fixed point support that will be not binary compatible between the Atmel branch and GCC. > Now that I have successfully built gcc, binutils and avr-libc supporting > all AVR devices offered by Atmel, would it be worth my while trying to > submitting these changes to the official releases ? Notice you must have passed the paperwork. If not, you can request a form in the g...@gcc.gnu.org mailing lists and they will send you the form you can send to the FSF. I don't see a reason why not to submit the patch for review. Coordinating with other developers in nice, and up to now I never saw that two developers want to implement the same feature -- the problem is the other way round: there are no contributors at all to implement a feature / bug fix... Johann _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
