Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[nightwalker-87]

Package: gcc-avr
Version: 1:5.4.0+Atmel3.6.1-2
Severity: normal
Tags: newcomer

Dear Maintainer,

It appears that the gcc-avr toolchain in the debian repository is severely
outdated compared to the current level of version support for the main gcc
toolchain. This leaves avr-developers wishing to use newer C language features
behind and makes it necessary to use external toolchains (source based or pre-
compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
following idea: "if it was in mainline, the gcc-avr package could be dropped in
favour of a package built from the mainline version of gcc." as well as "an
example of such a source package is gcc-arm-none-eabi, the equivalent for avr
could be added by someone interested, then gcc-avr could be removed." (user:
pabs) From my point of view this could be a promising approach to resume
development on this topic. I would appreciate, if debian developers could take
action on this topic to resolve this long lasting backlog and make contribution
to make debian even more attractive for development. As it stands the avr-8
architecture will remain for many years to come in some parts even with new
applications.



-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-avr depends on:
ii binutils-avr 2.26.20160125+Atmel3.6.1-4
ii libc6 2.28-10
ii libgcc1 1:8.3.0-7
ii libgmp10 2:6.1.2+dfsg-4
ii libmpc3 1.1.0-1
ii libmpfr6 4.0.2-1
ii libstdc++6 8.3.0-7
ii zlib1g 1:1.2.11.dfsg-1

gcc-avr recommends no packages.

Versions of packages gcc-avr suggests:
ii avr-libc 1:2.0.0+Atmel3.6.1-2
ii gcc 4:8.3.0-1
pn gcc-doc <none>

-- no debconf information

[Hakan Ardo]

Hi, 

gcc-avr was originally built from the mainline gcc, but was later split out by to build depend on gcc-source as it was not wanted in the mainstream gcc package. Has that situation changed? 

It was then decided to base the package on the Atmel distribution instead of the upstream source as that gave support for newer devices faster. 

Now, as far as I can tell, Atmel have dropped their source distribution and only provided binaries. So something have to be done indeed. 

Switching back to use upstream source would be one option. But will that mean we'll have to dropp support for newer devices? 

[nightwa...@t-online.de]

Dear Hakan,

Thank You very much for your quick reply.

Unfortunately I don’t know too much about the development history of this package @Debian and the related decisions.

It would be helpful though to have other developers and maintainers to have their say on this to help find a common solution.

At first one should find out if support for newer devices would suffer from such an approach. I have not come across that topic yet...

Best regards

Nightwalker-87

[nightwa...@t-online.de]

Hi Hakan,

pointing to this issue in a developer discussion and also this link (https://savannah.nongnu.org/forum/forum.php?forum_id=8460) led to the maintainer Jörg Wunsch.

It looks like as if he could be one of the key persons to address regarding this issue, as the key-package avr-libc has a dependency on gcc-avr which determines device compatibility.

The obviously current state of device support for avr-libc 2.0.0 as part of the latest AVR-toolchain 3.6.1 by Microchip can be found here: https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html.

Would that mean that a new version of avr-libc with full compatibility to gcc 8.3 (for example) could ease portability of the complete toolchain, while preserving device support at the same time?

Another info I came across is that the distribution Arch Linux maintains a very recent version of the toolchain (https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html).

Would it be possible to port these sources to the Debian? How did the maintainers at Arch manage to achieve compatibility with the latest gcc-mainline? According to the package content this is even based on avr-libc 2.0.0.

Do they have limitations regarding device support?

Nightwalker-87

[Osamu Aoki]

Hi,

This is a review of CC/C++ for AVR.

Debian Buster:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-======================-============-===================================
ii avr-libc 1:2.0.0+Atmel3.6.1-2 all Standard C library for Atmel AVR de
ii avrdude 6.3-20171130+svn1429-2 amd64 software for programming Atmel AVR
ii gcc 4:8.3.0-1 amd64 GNU C compiler
ii gcc-avr 1:5.4.0+Atmel3.6.1-2 amd64 GNU C compiler (cross compiler for
ii gdb-avr 7.7-4+b12 amd64 GNU Debugger for avr

Choice of CC/C++ for AVR can be several choices. As I googled situation, it looks
like:

(1) Hard ware vendor (microchip) supported CC:
GCC 5.4.0 based gcc-avr (current state in Debian)

Yah... it's old compared to the normal GCC 8.3 on buster
The vendor seems to have no intent to move to newer GCC.

(2) Latest GCC used as the cross-compiler:
Grntoo promote this: https://wiki.gentoo.org/wiki/Arduino

But it doesn't look good in near future ....
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
https://www.reddit.com/r/linux/comments/e3flt6/bountysource_campaign_to_modernize_the_avr/
https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now
GCC 10: AVR is deprecated
GCC 11: AVR will be dropped

So moving to the latest GCC is not easy to do.

(3) Forward port vendor patches by someone
GCC 9.2 ??? by Archlinux
https://www.archlinux.org/packages/community/x86_64/avr-gcc/

GCC 9.1 by stevenj
https://github.com/stevenj/avr-gcc-build-script/releases/tag/20190728
https://www.avrfreaks.net/forum/avr-gcc-91-avr-libc-xmega3-device-support

Following such efforts seems fragile at best ... we don't even know
how well they are tested.

(4) Stable updated GCC with forward ported vendor patches supported by
the active user community --- Arduino
Arduino 1.8.10 (Larest release)
avr-gcc-7.3.0

Considering gcc-avr is mostly aimed for use with Arduino platform and
Arduino forks seem to maintain and test GCC well, switching the UPSTREAM
of this Debian package to the Arduino ine seems good idea.

Arduino seems to just download binary from:
http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-apple-darwin14.tar.bz2

So we need to find where is the source of above package.

Osamu

[Osamu Aoki]

Hi

(The URL for avr-gcc for Linux in my previous post was wrong but it
isn't important ...)

Arduino seems to built avr-gcc with
https://github.com/arduino/toolchain-avr

It's opening page states:
binutils-2.26
gcc-5.4.0
avr-libc-2.0.0
gdb-7.8

Not gcc-7.3.0 as released as 1.8.10 at
https://www.arduino.cc/en/Main/Software
as I see today. It seems to patch upstream a bit.

Further check realized that, staging branch was using gcc-7.3.0 in code
https://github.com/arduino/toolchain-avr/commit/3e30e20948a5e3445823ecef23c007937b36583e
The applied patches are extensive!!! (Readme.md was not updated yet)

So this is one key resource. Providing both avr-gcc 5.4.0 and 7.3.0 as
patched by Arduino toolchain-avr main and staging branches with
update-alternatives may be the best for next release.

I also found
https://gcc.gnu.org/gcc-10/changes.html#avr

| Support for the XMEGA-like devices
|
| ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406,
| ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606,
| ATtiny1607, ATmega808, ATmega809, ATmega1608, ATmega1609,
| ATmega3208, ATmega3209, ATmega4808, ATmega4809
|
| has been added.
| A new command line option -nodevicespecs has been added. It allows
| to provide a custom device-specs file by means of
|
| avr-gcc -nodevicespecs -specs=my-spec-file <options>
|
| and without the need to provide options -B and -mmcu=. See AVR
| command line options for details. This feature is also available in
| v9.3+ and v8.4+. New command line options -mdouble=[32,64] and
| -mlong-double=[32,64] have been added. They allow to chose the size
| (in bits) of the double and long double types, respectively. Whether
| or not the mentioned layouts are available, whether the options act
| as a multilib option, and what is the default for either option is
| controlled by the new AVR configure options --with-double= and
| --with-long-double=. A new configure option --with-libf7= has been
| added. It controls to which level avr-libgcc provides 64-bit
| floating point support by means of Libf7. A new configure option
| --with-double-comparison= has been added. It's unlikely you need to
| set this option by hand.

So gcc-10 had some AVR support efforts.

Osamu

[Osamu Aoki]

Hi again,

I checked meaning of GCC versions.

GCC development time lines:
https://gcc.gnu.org/develop.html#timeline

As for ISO C99 conformance:
https://gcc.gnu.org/c99status.html

The last mentioned version was GCC 5 for "extended identifiers". So GCC
5 as supported by the vendor (microchip) isn't bad choice for C programs
mostly used by embedded programs.

Since Arduino sketches are in-essence C++ program(*), let's see C++
conformance:
https://gcc.gnu.org/projects/cxx-status.html

For C++14, GCC 5 is good enough.
For C++17, GCC 7 is needed and is good enough.
For C++2a, GCC 8-10 are addressing some features.

Unicode UTF-8 support is important. This u8 character literals support
is made available at GCC 6 as a part of C++17 feature:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
https://gcc.gnu.org/gcc-6/changes.html#cxx

This kind of explains why Arduino is updating GCC 7.

Osamu

(*) https://github.com/arduino/arduino-preprocessor
https://github.com/arduino/arduino-builder
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

[Hakan Ardo]

Hi,

thanx a lot for the great summary of the situation! Historically, the issue with "community" versions of the avr toolchain have been the lack of support for all AVR devices. Especially newer once. I don't know what the situation is there with the Arduino toolcahin.

I agree that providing two version of gcc (one with Arduino as upstream and one with microchip) is probably the best solution. That will however require some packaging work, and I'm afraid that my current personal situation wont allow me to put in that work anytime soon. But I will gladly support it if anyone steps up to do the work.

So, the plan is to have a new release based on Atmel-3.6.2 from microchip soon, and we can then make a separate release adding the Arduino version as an alternative once it is packaged.

--

Håkan Ardö

[Osamu Aoki]

Hi,

On Sun, Jan 12, 2020 at 08:36:49AM +0100, Hakan Ardo wrote:
> Hi,
> thanx a lot for the great summary of the situation! Historically, the
> issue with "community" versions of the avr toolchain have been the
> lack of support for all AVR devices. Especially newer once. I don't
> know what the situation is there with the Arduino toolcahin.

https://github.com/arduino/toolchain-avr/issues/60
Update toolchain to include ATmega_DFP 1.2.209

https://github.com/arduino/toolchain-avr/issues/48
toolchain 3.6.0 produces wrong binary with 328p target

It looks like Arduino is porting microchip updates on GCC 5 to GCC 7.

toolchain-avr is a shell script to download upstream sources, patching
them, and building them.

The staging branch's toolchain-avr/avr-gcc-patches/ has

* 0001-gcc-lto-wrapper.patch
* atmel-patches-gcc.5.4.0.patch
* atmel-patches-gcc.5.5.0.patch
* atmel-patches-gcc.6.5.0-arduino1.patch
* atmel-patches-gcc.7.3.0-arduino2.patch

> I agree that providing two version of gcc (one with Arduino as
> upstream and one with microchip) is probably the best solution. That
> will however require some packaging work, and I'm afraid that my
> current personal situation wont allow me to put in that work anytime
> soon. But I will gladly support it if anyone steps up to do the work.

> So, the plan is to have a new release based on Atmel-3.6.2
> from microchip soon, and we can then make a separate release adding
> the Arduino version as an alternative once it is packaged.

I see. It is new location.
AVR 8-bit Toolchain 3.6.2 - Linux 64-bit
https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers

But U only see binaries. Where is the source???

Arduino still seems to be using Atmel-3.6.1 for both master and staging.
Here is a log from staging.

+ source build.conf^M
++ AVR_VERSION=3.6.1^M
++ BUILD_NUMBER=arduino5^M
++ AVR_SOURCES=http://downloads.arduino.cc/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1^
++ ATMEL_PACKS_SOURCES=http://packs.download.atmel.com/^M
++ GNU_SOURCES=https://ftp.gnu.org/gnu/^M
++ MPC_SOURCES=http://repository.timesys.com/buildsources/m/mpc/^M
++ GCC_VERSION=7.3.0^M
++ MPFR_VERSION=3.1.0^M
++ ATMEL_ATMEGA_PACK_VERSION=1.3.300^M
++ ATMEL_ATMEGA_PACK_FILENAME=Atmel.ATmega_DFP.1.3.300^M
++ ATMEL_ATMEGA_PACK_URL=http://packs.download.atmel.com//Atmel.ATmega_DFP.1.3.300.atpack^
++ ATMEL_ATTINY_PACK_VERSION=1.3.229^M
++ ATMEL_ATTINY_PACK_FILENAME=Atmel.ATtiny_DFP.1.3.229^M
++ ATMEL_ATTINY_PACK_URL=http://packs.download.atmel.com//Atmel.ATtiny_DFP.1.3.229.a

I don't know if patches applied addresses 3.6.2 changes.

Anyway, this script build:
* avr-gcc
* avr-gdb
* avr-libc
* binutils

At this moment, I have build failure for avr-gdb for both master and
staging branch and I don't have time to figure out now ...

Considering our resource limitation, sticking with 5.0 may be good idea.

Supporting both GCC 5 and GCC 7 for libc, gdb ... may be a headache.

Anyway I now know even current Debian GCC 5 one is good for my needs.

Thanks for your work.

Osamu

PS: I am figuring out to use ARDUINO 1.8.10 on Debian buster.

[George Chapman]

> But U only see binaries. Where is the source???

https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive

via
https://www.avrfreaks.net/forum/where-have-atmel-avr-gcc-sourcecode-gone#comment-2742731

though it's walled; will need a myMicrochip account to get a copy.

[Benjamin Valentin]

I just compared the --mmcpu options of my avr-gcc 5.4.0 with [0]
and I don't see any missing device family upstream.
Is there a list of hardware that is only supported by the Microchip
fork?

There are also patches posted to port the upstream AVR backend to CC0
(see [1])

[0] https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/AVR-Options.html
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

[Benjamin Valentin]

Just comparing the output of avr-gcc --target-help gives

--- gcc-5.4.txt 2021-02-11 09:56:37.490084599 +0100
+++ gcc-10.2.txt 2021-02-11 09:56:30.918162094 +0100
@@ -160,9 +160,14 @@
attiny13
attiny13a
attiny15
+attiny1614
+attiny1616
+attiny1617
attiny1634
attiny167
attiny20
+attiny212
+attiny214
attiny22
attiny2313
attiny2313a
@@ -173,8 +178,13 @@
attiny261
attiny261a
attiny28
+attiny3214
+attiny3216
+attiny3217
attiny4
attiny40
+attiny412
+attiny414
attiny416
attiny417
attiny4313
@@ -186,6 +196,7 @@
attiny461a
attiny48
attiny5
+attiny814
attiny816
attiny817
attiny828

So gcc10 actually knows about some more parts.
I don't know if there are any missing patches upstream though.
Arch seems to carry the latest upstream gcc for AVR with no complaints
though.

[Hakan Ardo]

OK, so upstream does indeed currently seem to be ahead. That has not always been the case historically. I'm fine with switching if anyone steps up to do the work. I've put the packages up for adoption, but I'll be happy to give some support...

--

Håkan Ardö

[Gregor Riepl]

>> Switching back to use upstream source would be one option. But will
>> that mean we'll have to dropp support for newer devices?

> Unfortunately I don’t know too much about the development history of
> this package @Debian and the related decisions. It would be helpful
> though to have other developers and maintainers to have their say on
> this to help find a common solution. At first one should find out if
> support for newer devices would suffer from such an approach. I have
> not come across that topic yet...

To be honest, I don't think newer device support is a big issue any
more. While Microchip is still releasing new AVR MCUs, they are usually
not that different from existing devices. Even if Debian is lagging
behind, I think developers targeting older devices will benefit greatly
from an updated gcc. If they must, they can always rely on the binary
releases provided by Microchip.

It's also not that hard to feed in support for new devices:
https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices

And last but not least, upstream has kept pace with new AVR devices, as
can be seen in the gcc release notes:

https://gcc.gnu.org/gcc-7/changes.html#avr
https://gcc.gnu.org/gcc-8/changes.html#avr
https://gcc.gnu.org/gcc-10/changes.html#avr

I believe it's time to make the switch - same for binutils-avr and avr-libc.

[Gregor Riepl]

Please disregard my last message, I totally missed the whole discussion
that has already been going on.

Sorry.

[Hakan Ardo]

I believe your right, and I would support any such efforts. I've orphaned these packages quite some time ago as I've not been able to find the time to implement this myself though. 

--

Håkan Ardö

[Hakan Ardo]

No worries. Thanx for caring!

--

Håkan Ardö

[Marco]

What's the current status? This bug is almost 3 years old and Debian
is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
Arch Linux may have found a working solution:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20

[Hakan Ardo]

There is no progress I'm afraid. The package is up for adoption. We need to find someone who's willing to put in the time needed...

--

Håkan Ardö

[Nightwalker-87]

Hi,

Microchip has updated it's official AVR-toolchain in May 2022 as well
and provided related technical details.

https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers

Please (at least) port this version into the debian package sources ASAP.
Debian seems to have lost track with recent developments for this
architecture, resulting in lacking support for newer devices.
This is deeply disappointing to see.

Nightwalker-87