building gcc=8.3, avr-libc on Linux w/ atpack hooks

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

Below are my notes on building binutils, gcc and avr-libc with hooks for atpacks.  Why?  I can compile for atmega4809 now.

In the following I'm installing under /opt/local.   If you want to install elsewhere, make appropriate substitutions.

I use bash.  If you use a non-Bourne based shell, make appropriate adjustments.

 

  1.  Download Sources and ATPACK
    + get binutils-2.32 from http://ftp.gnu.org/gnu/binutils
    + get gcc-8.3.0 from mirror listed in https://www.gnu.org/software/gcc...
    + get gmp-6.1.0, mpfr-3.1.4, mpc-1.0.3, isl-0.18 from ftp://gcc.gnu.org/pub/gcc/infras...
    + get avr-libc from https://svn.savannah.nongnu.org/... using
       $ svn checkout svn://svn.savannah.nongnu.org/avr-libc/trunk
    + get device pack from http://packs.download.atmel.com
  2. Build and Install binutils
    $ tar xf binutils-2.32.tar.gz
    $ cd binutils-2.32
    $ ./configure --prefix=/opt/local --program-prefix=avr- --target=avr
    $ make
    $ sudo make install
    $ cd ..
  3. Build and Install gcc
    $ tar xf gmp-6.1.0.tar.bz2
    $ tar xf mpfr-3.1.4.tar.bz2
    $ tar xf mpc-1.0.3.tar.gz
    $ tar xf isl-0.18.tar.bz2
    $ tar xf gcc-8.3.0.tar.gz
    $ cd gcc-8.3.0
    $ ln -s ../gmp-6.1.0 gmp
    $ ln -s ../mpfr-3.1.4.tar.bz1 mpfr
    $ ln -s ../mpc-1.0.3 mpc
    $ ln -s ../isl-0.18 isl
    $ cd ..
    $ mkdir gcc-build
    $ cd gcc-build
    $ ../gcc-8.3.0/configure --prefix=/opt/local --program-prefix=avr- --target=avr --enable-languages=c,c++
    $ make
    $ sudo make install
    $ cd ..
  4. Build and Install avr-libc
    $ cd trunk/avr-libc
    $ export PATH=/opt/local/bin:$PATH
    $ ./bootstrap
    $ ./configure --prefix=/opt/local --host=avr
    $ make
    $ sudo make install
    $ cd ../..
  5. Transfer Appropriate Files from the Device Pack
    $ mkdir dev-pack
    $ unzip ../Atmel.ATmega_DFP.1.3.300.atpack
    $ cp .../xfer-pack .
    $ [edit] xfer-pack    # <= use editor to adjust paths in included shell script
    $ sh xfer-pack
    $ cd ../
  6. Try it out
    $ avr-gcc -DF_CPU=16000000 -mmcu=atmega4809 -Os -B/opt/local/avr/packs/1.3.300 -B/opt/local/avr/packs/1.3.300/lib/avrxmega3 -o main.elf main.c

 

Notes:

  1. Though the notes in gcc-8.3.0 say older versions of mpfr etc can be used, I found I needed the latest versions.
  2. Make sure when you build avr-libc your "avr-gcc" command is the 8.3.0 version and not something older.

 

The program "xfer-pack":

#!/bin/sh

# Define source and target directories.

pack_dir=/var/tmp/MattRW/dev-pack
dest_dir=/opt/local/avr/packs/1.3.300

devs_dir=$pack_dir/gcc/dev
if [ ! -d $devs_dir ]; then
  echo "*** bad directory: $devs_dir"
  exit 1
fi
devs=`(cd $devs_dir; ls)`

# Start building destination.
mkdir -p $dest_dir

# Install include files.
#mkdir -p $dest_dir/include
#(cd $pack_dir/include; tar cf - . ) | (cd $dest_dir/include; tar xf -)

# Install device-spec files.
mkdir -p $dest_dir/device-specs
for dev in $devs; do
  cp $devs_dir/$dev/device-specs/specs-$dev $dest_dir/device-specs/
done

# Install lib files.
mkdir -p $dest_dir/lib
for dev in $devs; do
  for dir in `ls $devs_dir/$dev`; do
    case $dir in
    device-specs) ;;
    *) (cd $devs_dir/$dev; tar cf - $dir) | (cd $dest_dir/lib; tar xf -) ;;
    esac
  done
done

# --- last line ---

 

Last Edited: Tue. May 21, 2019 - 01:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. You can simplify installing GCC prerequisites by running ./contrib/download_prerequisites from GCC top source (as explained in "Installing GCC"). This will download and link for in-tree build the recommended versions of: GMP, MPFR, MPC, ISL.
.
2. Just as with GCC, building in a separate build directory is usually preferable over messing up the source by building in the source dir. If something does not work as expected, it's much easier to clean up.
.
3. If one feels uncomfortable with sudo, just use prefix somewhere in your HOME. This also makes "uninstall" easier: it's just rm -rf
.
4. I'd recommend to add --with-gnu-as --with-gnu-ld --disable-nls. The latter also for Binutils if you want to avoid awkward native language diagnostics.
.
5. You can specify the build compiler for avr-libc by "make CC=...". IIRC avr-libc takes the compiler it finds in prefix?

avrfreaks does not support Opera. Profile inactive.

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

Thank you for these detailed instructions!

 

When building GCC I end up with:

 

configure: error: in `/home/d/devel/avr/toolchain/gcc-build/gcc':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
Makefile:4199: recipe for target 'configure-gcc' failed
make[1]: *** [configure-gcc] Error 1
make[1]: Leaving directory '/home/d/devel/avr/toolchain/gcc-build'
Makefile:890: recipe for target 'all' failed
make: *** [all] Error 2

 

Any ideas?

 

(And when do we get support for the latest ATtinies without having to find Dev Packs?)

 

Long time AVR user but more fond of analog electronics than compiler details...

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

vfz wrote:
Any ideas?
Well just on the basis of the message shown:

See `config.log' for more details.

did you?

 

As for packs - I think you are always going to need packs from now on aren't you? Any "new device" is always going to be in the packs before the mainline (which is kind of the reason for putting things into packs in the first place - so things don't have to keep being rebuilt).

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

clawson wrote:
did you?
  Yes. But being primarily an electronics designer and not a programmer I think it is hard to know what to look for. However I did now find a row about missing g++ and installing this package seemed to fix the CPP-problem. It's a pity that this was not caught earlier in the script.

 

About packs, let me then reformulate: When do we get support in the compiler and avr-libc such that they don't have to be built from source?

Being used to the flawless support in avr-gcc, avr-libc and avrdude for mega88 and friends I find it hard to understand why (and how) I now need to compile and download this and that to get my tool chain working for chips like attiny817 that have been around for three years already.

 

Thanks!

Long time AVR user but more fond of analog electronics than compiler details...

Last Edited: Tue. Jun 25, 2019 - 02:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The situation used to be this. There was the FSF copy of GNU GCC and anyone could work on the AVR variant in that. Atmel chose to take a branch private and got to the point where there branch was generally 12..18 months ahead of the mainline. Anyone who wanted support for a "recent processor" therefore had to wait for Atmel to issue builds off their development branch (something they generally did once every 12..18 months too). Slowly but surely they would push their work back upstream in to the mainline but it always lagged. Recognising this to be a problem they chose to use "packs" (-B) so that issues of "new stuff" could be bolted on to previously issued compilers with the need for a constant build cycle. In theory this is "Good News" for those outside the Atmel branch - you should be able to build later GCCs (like 8's and 9's) from the mainline and then apply the "recent CPU" knowledge to it using packs.

 

So if you build mainline then apply Atmel packs to it you should have 817 support shouldn't you? (that was their plan anyway).

 

PS unless you desperately need an 8 or a 9 or similar then why not simply take the most recent Atmel build .tar.gz for Linux ?

Last Edited: Tue. Jun 25, 2019 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe this thread would get more deserved visibility in the tutorials section?

 

Anyway, now I want to rant a bit. For some reason, more recent versions of avr-gcc seem to be doing a poorer job at size optimization.

I did some tests, compiling an open project I have at github: https://github.com/ElTangas/jtag...

 

The compile optimization flags are -Os -funsigned-char -funsigned-bitfields -fno-jump-tables -flto -fno-gcse -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax

 

Resulting binary sizes:

v. 5.4.0 -> 2620 bytes

v. 7.3.0 -> 2436 bytes

v. 8.0.1 -> 2438 bytes

v. 8.1.0 -> 2438 bytes

v. 8.3.0 -> 2442 bytes

v. 9.1.0 -> 2591 bytes

 

Sure, this is just one example so it has no statistical meaning. But I feel this is not an isolated case. In practice, I normally use v. 8.1.0 or v. 8.3.0 because the earlier ones have a few bugs I don't like. But v. 9 is quite a disappointment.

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

Again this is because a lot of the core of GCC (the target independent bits) are actually optimised for ARM and x86/x64 so something that helps the ARM code generation might have an adverse impact on AVR (even if the final AVR code generation steps are as efficient as they can possibly be).

 

Also, just theoretically, consider the situation where a bug fix adds register preservation/restoration that might have been dangerously missing previously. That kind of thing generates more code but the point is that it's more accurate/faultless so it's a trade-off.

 

However that is quite a jump from 8.3 to 9.1 though - have you studied it to see exactly where the bloat has been introduced?

 

PS Atmel's Linux issue is 5.4

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

clawson wrote:
However that is quite a jump from 8.3 to 9.1 though - have you studied it to see exactly where the bloat has been introduced?

 

It seems to be lots of small things that slowly add up, for example (I removed -flto so that I'm able to follow the code better):

 

v. 8.3.0

 35a:	1f ef       	ldi	r17, 0xFF	; 255
 35c:	18 0f       	add	r17, r24

v. 9.1.0

 35a:	ff 24       	eor	r15, r15
 35c:	fa 94       	dec	r15
 35e:	f8 0e       	add	r15, r24

What happens here, is that a function call immediately follows these instructions but the compiler needs to save (r24-1) for later in a call preserved register. The new version chooses r15 instead of r17, so ldi cannot be used, and a 2 instruction sequence is generated to put -1 in r15. So, poor decisions on register allocation by the new version.

 

later...

v. 8.3.0

 3d0:	90 df       	rcall	.-224    	; 0x2f2 <_ZN7JICE_io3getEv>
 3d2:	f8 01       	movw	r30, r16
 3d4:	81 93       	st	Z+, r24
 3d6:	8f 01       	movw	r16, r30
 3d8:	be 01       	movw	r22, r28        ; saved uint16_t return value from previous cycle is argument for this cycle
 3da:	76 df       	rcall	.-276    	; 0x2c8 <_ZN3CRC4nextEhj>
 3dc:	ec 01       	movw	r28, r24        ; preserve uint16_t return value on r28:r29, which are call preserved
 3de:	0e 15       	cp	r16, r14
 3e0:	1f 05       	cpc	r17, r15
 3e2:	b1 f7       	brne	.-20     	; 0x3d0 <_ZN5JTAG27receiveEv+0x2a>

 

v. 9.1.0

 3d4:	8e df       	rcall	.-228    	; 0x2f2 <_ZN7JICE_io3getEv>
 3d6:	f8 01       	movw	r30, r16
 3d8:	81 93       	st	Z+, r24
 3da:	8f 01       	movw	r16, r30
 3dc:	6d 2f       	mov	r22, r29        ; as above, the return value from the previous cycle is restored, but since
 3de:	7c 2f       	mov	r23, r28        ; it was not saved using movw, now movw can't be used to restore it, either... 
 3e0:	73 df       	rcall	.-282    	; 0x2c8 <_ZN3CRC4nextEhj>
 3e2:	d8 2f       	mov	r29, r24
 3e4:	c9 2f       	mov	r28, r25        ; preserve return value but store in reverse order so movw can't be used (!)
 3e6:	0e 15       	cp	r16, r14
 3e8:	1f 05       	cpc	r17, r15
 3ea:	a1 f7       	brne	.-24     	; 0x3d4 <_ZN5JTAG27receiveEv+0x2c>

 

Man this one is egregious... whyyyy???

 

Well, you get the picture, these small things throughout the code add up.

Last Edited: Wed. Jun 26, 2019 - 01:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
PS unless you desperately need an 8 or a 9 or similar then why not simply take the most recent Atmel build .tar.gz for Linux ?

 

You mean from Microchip? https://www.microchip.com/mplab/...

I didn't even know that it was available until I did some searching based on this comment of yours. Their documentation, when starting at microchip.com and going forward to the AVR section, really lacks a lot. Also the docs for the kits (like attiny817 xplained mini) doesn't tell you much about the options available.

What I normally use is the pre-built deb package available in my distro, which currently is 1:5.4.0+Atmel3.6.0-1build1. Is there a reason why it lags behind? And how can I know what GCC version is it built for?

 

Thank you for your comments. Very valuable.

Long time AVR user but more fond of analog electronics than compiler details...

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

vfz wrote:

What I normally use is the pre-built deb package available in my distro, which currently is 1:5.4.0+Atmel3.6.0-1build1. Is there a reason why it lags behind? And how can I know what GCC version is it built for?

 

Thank you for your comments. Very valuable.

But the DEB repo maintainers are more than likely going to be pulling source from FSF-GNU not applying the (also available) later Atmel patches to it. So their 5.4.0 is not going to have as extensive a range of devices as the 5.4.0 that Atmel build out of their own development branch. That's why it simply makes most sense to just google "Microchip AVR toolchain linux" or simply go straight to  https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers  then get  AVR 8-bit Toolchain 3.6.2 - Linux 64-bit (I assume your Linux is 64 bit - else get the 32 bit one).

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

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

Dependent on the contents of an Atmel server per

https://sources.debian.org/src/gcc-avr/1:5.4.0+Atmel3.6.1-2/debian/watch/

 

So no more updates for that package too , as µChip hasn't fixed the atmel server containig the sources   :

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/

 

I have an open PR with them , about them releasing the 3.6.2 sources , as per GPL.

 

They keep comming with "Bad excuses" , and no source.

 

I'm seriously considering to report them to  GNU

https://www.gnu.org/licenses/gpl...

 

 

/Bingo

Last Edited: Wed. Jun 26, 2019 - 07:41 PM