Re: AVR32 support in crosstool-ng

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

On 4/29/2013 1:23 PM, Martin Guy wrote:
> Hi!
>    I'm writing because I've updated the AVR32 support in crosstool-ng
> to gcc-4.2.4, gcc-4.3.{3,6}, gcc-4.4.{3,7}, binutils-2.22 and all
> versions of newlib, giving smaller code size at every step (which was
> the whole point).
>     However I don't feel that it's appropriate to include these patches
> in mainline crosstool-ng for two reasons:
> 1) They're enormous: about a megabyte of patches for each version of
> gcc, binutils and newlib version, and that's *after* trimming them to
> the bare minimum, increasing the patches/ directory from 10MB to 15MB.
> 2) They need to modify toolchain components outside the avr32 files.
> These changes are most likely harmless in binutils but in gcc they
> introduce extra mysterious transformations in cpu-agnostic parts of
> gcc, sometimes claiming in commentary that these changes should be OK
> for other processors.
>
>     Is there a way in GCC to say, in generic code, "#if building a
> compiler targetting AVR32"? It sems unlikely as it foes against the
> whole philosophy of keeing architecture-specific code in their own
> subdirectories, but would make it possible to produce AVR32 patches
> that don't change the behaviour of the tools when they are compiling
> for other CPU architectures.
>
> In the light of this, I've been hacking a copy of crosstool-ng at
> http://spaces.atmel.com/gf/project/ct-ng
>    The only changes are the addition of patch files, all of which have
> "avr32" in the name and the addition of a default .config file.
I'm asking this in the general sense. Why doesn't Atmel submit their patches
upstream?

Even the regular AVR requires multiple unsubmitted patches
(19 if I remember correctly) and that port is in the FSF repository.

I saw similar bitrot and aging this weekend when I checked on
the msp430. Just unsubmitted code hanging around getting older
and further from the main stream.

As an embedded FOSS community, we need to be encouraging
vendors.. prodding them.. to submit their tools upstream.

>    Can you let me know how this affects mainline crosstool-ng? Whether
> wholesale support for new architectures is welcome or whether maybe a
> tarball in the contrib/ directory would be more suitable?
>
> Thanks again
>
>      M
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq


--
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


--
For unsubscribe information see http://sourceware.org/lists.html#faq