* AVR32 support in crosstool-ng @ 2013-04-29 18:23 Martin Guy 2013-04-29 18:29 ` Joel Sherrill 2013-05-03 15:04 ` Yann E. MORIN 0 siblings, 2 replies; 6+ messages in thread From: Martin Guy @ 2013-04-29 18:23 UTC (permalink / raw) To: Crossgcc list 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. 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVR32 support in crosstool-ng 2013-04-29 18:23 AVR32 support in crosstool-ng Martin Guy @ 2013-04-29 18:29 ` Joel Sherrill 2013-04-29 19:49 ` Martin Guy 2013-05-03 15:04 ` Yann E. MORIN 1 sibling, 1 reply; 6+ messages in thread From: Joel Sherrill @ 2013-04-29 18:29 UTC (permalink / raw) To: Martin Guy; +Cc: Crossgcc list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVR32 support in crosstool-ng 2013-04-29 18:29 ` Joel Sherrill @ 2013-04-29 19:49 ` Martin Guy 2013-04-29 20:11 ` Joel Sherrill 0 siblings, 1 reply; 6+ messages in thread From: Martin Guy @ 2013-04-29 19:49 UTC (permalink / raw) To: Joel Sherrill; +Cc: Crossgcc list On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote: > Why doesn't Atmel submit their patches upstream? They would never be accepted as long as they make modifications to cpu-agnostic portions of GCC. > As an embedded FOSS community, we need to be encouraging > vendors.. prodding them.. to submit their tools upstream. Absolutely. After all, chip vendors make their money by selling silicon, not compilers. But it's not only a technical issue. The GCC maintainers also need to believe that the port will continue to be maintained, tested, the code updated to new versions of GCC, that bugs found will be fixed and so on, i.e. a commitment from the vendor to help with to the ongoing work of software maintenance. M -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVR32 support in crosstool-ng 2013-04-29 19:49 ` Martin Guy @ 2013-04-29 20:11 ` Joel Sherrill 2013-05-02 13:27 ` Martin Guy 0 siblings, 1 reply; 6+ messages in thread From: Joel Sherrill @ 2013-04-29 20:11 UTC (permalink / raw) To: Martin Guy; +Cc: Crossgcc list On 4/29/2013 2:49 PM, Martin Guy wrote: > On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote: >> Why doesn't Atmel submit their patches upstream? > They would never be accepted as long as they make modifications to > cpu-agnostic portions of GCC. Yep. But it speaks poorly of the port if they did that and didn't try to find a way to address it. :) >> As an embedded FOSS community, we need to be encouraging >> vendors.. prodding them.. to submit their tools upstream. > Absolutely. After all, chip vendors make their money by selling > silicon, not compilers. Agreed. > But it's not only a technical issue. The GCC maintainers also need to > believe that the port will continue to be maintained, tested, the code > updated to new versions of GCC, that bugs found will be fixed and so > on, i.e. a commitment from the vendor to help with to the ongoing work > of software maintenance. I understand completely. I am the GCC RTEMS maintainer. OTOH I wonder why a chip vendor would be opposed to this. Wouldn't they want an improving rather than dead end compiler?[1] And yes sometimes they pay someone to do the port and not to update it. So they don't have in-house expertise and there is no long plan to support it except maybe to pay the consultant again per bug. As a community, we just aren't doing a good job of selling the idea that merging and maintaining benefits both sides. It has to be cheaper to keep it up to date and tested versus jumping 4 or 5 major gcc versions. But it is cheaper to do the port, throw it to users and walk away. Sorry for the rant. I have managed to prod behind the scenes and get a couple of ports merged into the FSF. One was easy. One has been taken over two years and is just now getting merged. I just get frustrated when I see other targets out in the cold. [1] Both the msp430 and avr32 are based on gcc versions which are in the 4.3/4.4 version range. Those are dead. 4.6 was just closed. > M -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVR32 support in crosstool-ng 2013-04-29 20:11 ` Joel Sherrill @ 2013-05-02 13:27 ` Martin Guy 0 siblings, 0 replies; 6+ messages in thread From: Martin Guy @ 2013-05-02 13:27 UTC (permalink / raw) To: Joel Sherrill; +Cc: Crossgcc list On 29 April 2013 22:11, Joel Sherrill <joel.sherrill@oarcorp.com> wrote: > On 4/29/2013 2:49 PM, Martin Guy wrote: >> On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote: >>> As an embedded FOSS community, we need to be encouraging >>> vendors.. prodding them.. to submit their tools upstream. >> >> Absolutely. After all, chip vendors make their money by selling >> silicon, not compilers. > > Agreed. Sorry, I wasn't very clear here. What I mean is that chip vendors make money by selling silicon. To sell silicon, other companies have to decide to use the vendor's chips in new products, the choice of chip is influenced by their software developers' recommendations and good compiler support is a major factor for a software developer. Here's our story: Our company had chosen AVR32 for its price/performace ratio and for its GNU toolchain. After a year of development, we lost two whole months, right before the product launch, chasing a bug that made the completed software product freeze, apparently at random. It turned out to be due to a bug in all the AVR32 toolchains, that had been fixed years ago in a newer version of newlib. Not even in GCC. In newlib-1.16. As soon as I'd fixed that bug, another one showed up with the same symptoms: that the product runs for a bit then freezes. We didn;t bother investigating that, but distributed the product with the last binary versions of the s/w that had never been known to freeze. We stopped software development for that product because we couldn't guarantee to produce reliable firmware without another series of months chasing phantom toolchain bugs. The only reason I am struggling now with AVR32 GCC support is hoping to get a working compiler is to make a one-year-later update to the firmware for the old product. Atmel's compilers are still distributed with broken newlib. Management are telling me not to waste my time, as they have only lost money on the old product. They are now a bit funny in the head about Atmel chips, having been in hell for two months last year. They say the AVR32 is "dead and abandoned by Atmel". They were all ready to make the next product with PIC32, and asked me to evaluate the compiler support. There are GNU toolchains for PIC32. Microchip distribute have a free version with optimization turned off and they make you link to a closed-source binary object file to perform chip setup (crt0.o, if you like) with dire warnings about what will happen to you if you reverse engineer it. That's about as far as you can get bending the GPL without breaking it. So we dumped the PIC32 project, despite having already done the routing for the main board, and their next product will be based on ARM, who have been investing heavily in open source software tools and operating systems for years. Lord, a cross-toolchain for ARM is now even included in Ubuntu. Not that I like ARM's world-domination and would much rather support open hardware and CPU diversity. But when it comes to the difference between fifteen different high-quality recent toolchains and an ancient one full of bugs or one that mandates binary blobs... that is life or death to the product. I'm doing what I can for Atmel, or rather for its users. I did the same for Cirrus (or rather, their users) a few years back. Atmel seems to be making moves int hat direction, but doesn't really understand open source. Not the way ARM does. > As a community, we just aren't doing a good job of selling the idea that > merging and maintaining benefits both sides. It has to be cheaper to keep > it up to date and tested versus jumping 4 or 5 major gcc versions. But it is > cheaper to do the port, throw it to users and walk away. Cheaper, maybe, but less profitable. M -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVR32 support in crosstool-ng 2013-04-29 18:23 AVR32 support in crosstool-ng Martin Guy 2013-04-29 18:29 ` Joel Sherrill @ 2013-05-03 15:04 ` Yann E. MORIN 1 sibling, 0 replies; 6+ messages in thread From: Yann E. MORIN @ 2013-05-03 15:04 UTC (permalink / raw) To: Martin Guy; +Cc: Crossgcc list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-03 15:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-29 18:23 AVR32 support in crosstool-ng Martin Guy 2013-04-29 18:29 ` Joel Sherrill 2013-04-29 19:49 ` Martin Guy 2013-04-29 20:11 ` Joel Sherrill 2013-05-02 13:27 ` Martin Guy 2013-05-03 15:04 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).