avr build tools (mostly gcc-avr and ubuntu)

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a new thread split off from the original thread
that brought up an ISR() compiler bug related to avr gcc tools being out of date:

link to original thread:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=79106

to talk about proper avr-gcc build tools.

There seems to have been quite a bit
of turmoil in the tool set in the past 6-9 months.

To compound things distributions like
ubuntu 8.10 are distributing outdated
versions of gcc-avr that have some pretty
serious if not fatal flaws.

The "sticky" describes building and installing a toolset that seems to be based on an earlier revision of the compiler with patches that are older than what is available from the GCC master sources or from the Ubuntu 8.10 repository.

Even more interesting is that I went and looked at the intrepid gcc-avr development
page and changelog and their latest
version is 4.3.0-4 while the latest
version that shows up in the package
tool is 4.3.0-2

The change log shows 22 WinAvr patches
being applied to create 4.3.0-3 and
one patch to create 4.3.0-4
So it looks like all the proper patches
are happening on the ubuntu side, I'm
just not seeing them from the package side.

I'm only seeing 4.3.0-2 from the package manager.

=====================================
I've since updated a machine to ubuntu 9.04
and it uses 4.3.2-1 which does not have
the ISR() register bug.

======================================

I guess my main question is what is
considered to be the "golden" compiler version for development?

Is it the older 4.2.2 patched version referenced in the sticky or is 4.3.2-1 acceptable?

It does look like many bug fixes are
in 4.4 but perhaps some of those fixed were
introduced in 4.3.0

So perhaps I should focus on getting
the 4.4 tools up and running?

While I'm capable of building all the tools,
myself I'm also leaning twards pushing the ubuntu guys
to update their repositories with a version
of the tools that is stable so that newbies
can simply do an apt-get or use the
package manager to get their avr tools up
and running in 5-10 minutes instead of
having to go through the process of having to build it themselves on their own machines.

But before I start, I'd kind of like know what everyone considers to be the "gold standard" as far as revision of avr gcc build tools goes.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I guess my main question is what is
considered to be the "golden" compiler version for development?

For a Linux environment the older toolchain built using Bingo's sticky is most definitely the way to go. If one was going to put in effort it might be best directed at bringing that script up to date to get a later tooclhain and the relevant set of patches to be applied.

I think it's a pretty fair bet that anyone who's going to do AVR development in Linux is going to find themselves in this forum before very long and you'd kind of hope that any new visitors to a forum would always start by reading the stickies!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I think it's a pretty fair bet that anyone who's going to do AVR development in Linux is going to find themselves in this forum before very long and you'd kind of hope that any new visitors to a forum would always start by reading the stickies!

Which is exactly what I did.
I landed in this forum the very day I decided to start playing with AVRs.

But I think therein lies the problem -
at least for someone like me who has the knowledge and capability to build the full tool chain themselves.

The first thing I noticed was the title.
It references a version of the compiler (4.2.2) which at this point appears to be quite far behind.

The next thing that I noticed is that the thread is quite old.
Granted, the initial post has been maintained but for the most part it was not clear to me what version of the tools I was getting from this bundle.

It wasn't clear to me if this is a package of a downrev compiler (that some people prefer) in a build package that is being fixed/updated primarily to correct build script errors or whether it is also being updated to update the compiler itself even though it is still being called "4.2.2".

When I read the "AVR Toolchain buglist" sticky, I saw what looked like several severe bugs that were fixed in gcc versions beyond 4.2.2

Because of this, it made me wonder if I really wanted to use the tools referenced
in the AVR gcc 4.2.2 sticky.

So I initially installed the 4.3.0-2 version available in ubuntu 8.10 thinking that it would be "better".

After it became clear that this version had an ISR compiler bug, I started to dig a bit deeper.

The official gcc version of the compiler is now at 4.4.0

I downloaded that version straight from the GNU gcc SVN repository and built it.
Ok there was a minor build issue but I worked around it to get it built and installed.
That version does not have the ISR problem.

I've also had a look on the intrepid build site for gcc-avr. I'll admit to being a ubuntu newbie but it appears that they have made all the relevant patches and you can download a source package from there but it appears that the more recent builds are not available through the package system.

In the mean time I'll see if I can get
the ubuntu guys to update their gcc-avr
package on intrepid as this is a much
better and easier solution for most folks.

=========================================

How can I resolve what fixes are in the "4.2.2" sticky version of avr-gcc vs what shows up in the "AVR Tool Chain Bug list" sticky referenced vs what is in the official GCC sources?
Because right now, it appears that the 4.2.2 revision is behind and doesn't have many of these fixes. - some of which look pretty critical.

So I still have the question as to where to get a "golden" development environment and what revision of gcc to use.

Since I can build and install gcc 4.4.0, would I still want to use the gcc in the 4.2.2" sticky?

If the toolset in the "4.2.2" sticky
really is the "golden" version because it is really a later version of avr-gcc than 4.2.2 with many bug fix patches applied, perhaps the answer is simply to remove the existing "4.2.2" sticky and
create a new one that describes what it is and how to use it and doesn't call it "4.2.2".

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the best way to find a "contemporary" set of patches is to pull the latest WinAVR.

For example the latest issue contains 4.3.2 and you can see the toolchain patches that have been applied:

C:\WinAVR-20090313\source\gcc\4.3.2>dir *.patch /b
20-gcc-4.3.2-libiberty-Makefile.in.patch
21-gcc-4.3.2-disable-libssp.patch
23-gcc-4.3.2-ada-Makefile.patch
40-gcc-4.3.2-bug-10768-by-adacore.patch
41-gcc-4.3.2-bug-11259_v3.patch
42-gcc-4.3.2-bug-spill-v4.patch
43-gcc-4.3.2-bug-35013.patch
44-gcc-4.3.2-libgcc16.patch
45-gcc-4.3.2-bug-33009.patch
46-gcc-4.3.2-andsi3-wrong-attribute.patch
47-gcc-4.3.2-bug-38751.patch
48-gcc-4.3.2-bug-18145-v4.patch
50-gcc-4.3.2-mega256.patch
51-gcc-4.3.2-mega256-additional.patch
52-gcc-4.3.2-xmega-v12.patch
53-gcc-4.3.2-xmega2-v3.patch
54-gcc-4.3.2-atmega32m1.patch
55-gcc-4.3.2-atmega32c1.patch
56-gcc-4.3.2-atmega32u4.patch
57-gcc-4.3.2-attiny167.patch
58-gcc-4.3.2-remove-atmega32hvb.patch
59-gcc-4.3.2-attiny13a.patch
60-gcc-4.3.2-atxmega32a4.patch
61-gcc-4.3.2-newdevices.patch
62-gcc-4.3.2-newdevices2.patch
63-gcc-4.3.2-ata6289.patch
64-gcc-4.3.2-xmega-newdevices.patch
65-gcc-4.3.2-osmain.patch
70-gcc-4.3.2-ada-mlib.patch
71-gcc-4.3.2-ada-freestanding.patch
72-gcc-4.3.2-ada-timebase.patch
73-gcc-4.3.2-ada-gnat1_print_path.patch
74-gcc-4.3.2-ada-optim_static_addr.patch
75-gcc-4.3.2-builtins_v6.patch

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just updated the build scripts that I posted a while back. These are a much cleaned up version of those in the sticky thread. They currently build gcc 4.3.2 and friends, but it is easy to adjust them to another version (that ease of switching was one of the reasons I created them).

https://www.avrfreaks.net/index.p...

They should work on any current Linux version. On apt based Linux (like Debian, Ubuntu) they provide and extra feature and also install the packages you need to build the avr tools.

As for gcc versions, personally I've stuck with the versions that are used in the most current WinAVR release. I figure those are the best tested.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brad, that's a pretty nice set of scripts.
Probably easier for most folks than what is described in the sticky.

I guess what scares the crap out of me is all the patches which are being done on both the version in the sticky and in this updated version.

My overall question on this is how many of these are making it back into the main line gcc and avr-libc sources?

For example if I pull gcc 4.4.0 from the main gcc svn tree how many of the gcc patches will be in there?

Obviously some of them are making it in because when I built 4.4 from source I didn't see the ISR register save bug that I saw in the 4.3.0-2 binary release I pulled from the ubuntu 8.10 repository.

What about avr-libc? It looks like it is being updated fairly regularly.
Does it contain all the latest relevant updates/patches?

So if I pulled the latest gcc (say 4.4) and the latest avr-libc would those contain most if not all the patches that are being applied by Brads or the Sticky's build scripts?

I'm curious as to how in the world all these patches are being kept straight between all the various versions of the tools available.

Seems like a lot of work to track all these patches and even write scripts around them
vs using branches and tags in a CVS or SVN repository that people could use to checkout
or update their sources.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bperrybap wrote:
Brad, that's a pretty nice set of scripts.
Probably easier for most folks than what is described in the sticky.

Thanks. They've worked well for me. They also update binutils generated headers for new AVR devices, which I think is missing in the stick script.

Quote:
I guess what scares the crap out of me is all the patches which are being done on both the version in the sticky and in this updated version.

Seems like a lot of work to track all these patches and even write scripts around them
vs using branches and tags in a CVS or SVN repository that people could use to checkout
or update their sources.


If you look at the scripts that I posted in detail, you'll see that most patches are pulled from a CVS repository. That repoository is maintained by Eric Weddington (who works for Atmel). The CVS repository is organized by tool and release. So there are different directories for GCC/4.3.2 patches versus GCC/4.3.1 or binutils/2.19 patches, etc. Thanks to Eric it is well organized.

In the open source world it is very common to maintain a set of patches against an upstream project. This is actually much easier to manage than a full clone or branch. The choice of CVS as the source control system, however, I might question ;) More modern source control systems have tools specifically for managing patch sets.

Quote:
My overall question on this is how many of these are making it back into the main line gcc and avr-libc sources?

For example if I pull gcc 4.4.0 from the main gcc svn tree how many of the gcc patches will be in there?


Patches do make it back upstream, but I'm not sure how fast. GCC has pretty long test cycles, and it seems like there are always at least a few new device patches.

Binutils is the same deal. AVR-libc doesn't have many patches, I believe because it is released fairly often.

Quote:
So if I pulled the latest gcc (say 4.4) and the latest avr-libc would those contain most if not all the patches that are being applied by Brads or the Sticky's build scripts?

I don't know. It is much easier to just follow Eric's lead and let him organize all the patches for each GCC release.

Also note that GCC 4.4.0 has a new register allocator and various people have said that it is not yet well tested on AVR. The general consensus is to stick with the 4.3.x line for now. That is what WinAVR is doing for example.

-Brad