This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See crosstool-NG for lots more information.


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: AVR32 support in crosstool-ng


Martin, All,

On Mon, Apr 29, 2013 at 08:23:07PM +0200, Martin Guy wrote:
>   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.

Size is not the showstopper, IMHO. Someone willing to build a toolchain
will anyway need to download quite large tarballs (gcc, binutils...) so
afew more bytes for the crosstool-NG tarball is not really bad.

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

I'm very impressed by your updating the patches for AVR32.

But as you state yourself, I'd be more than cautious with those patches.
The most dubious in those patches (and it's not your fault) is that they
touch generic code, which smells.

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

Still, that would mean patching gcc (and binutils?), which is not really
acceptable I think.

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

I think it would make sense to add the patches as-is in the contrib
sub-dir, layed out as thus;

    contrib/avr32/patches/gcc/x.y.z
    contrib/avr32/patches/binutils/a.b.c

and so on; you get the point.

Then, anyone who wants to build an avr32 toolchain can still enable
those patches (with the bundled+local option in the menuconfig).
Or even copy them in place with the other patches.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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


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