Forum: Compiler & IDEs GCC v14 Release


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Seit einer Woche gibt es die neue GCC Release v14

Änderungen:
https://gcc.gnu.org/gcc-14/changes.html

AVR-spezifisch:
https://gcc.gnu.org/gcc-14/changes.html#avr

von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

Danke für dein stetiges Engagement. Und natürlich all die anderen 
Heinzelmännchen rund um avr-gcc mit Tools wie avrdude usw..

von Veit D. (devil-elec)


Lesenswert?

Hallo,

nur mal zur Info was der avr-gcc 14 leistet im Vergleich mit AVR128DB64.
1
avr-gcc  9.5.0 - Flash 24960 / RAM 3328 Bytes
2
avr-gcc 10.5.0 - Flash 25114 / RAM 3328 Bytes
3
avr-gcc 11.4.0 - Flash 25014 / RAM 3328 Bytes
4
avr-gcc 12.3.0 - Flash 24336 / RAM 3328 Bytes
5
avr-gcc 13.2.0 - Flash 24170 / RAM 3328 Bytes
6
avr-gcc 14.1.0 - Flash 24335 / RAM 2158 Bytes

Trotz 1k weniger "RAM Belegung" funktioniert meine Modelleisenbahn noch. 
:-) Man mag es kaum glauben.

(Formatierungs-Tags ergänzt, damit es auch mobil lesbar ist. - Mod.)

: Bearbeitet durch Moderator
von Oliver S. (oliverso)


Lesenswert?

Da es wohl einiges an const Daten geben, die du vorher manuell ins Flash 
hättest schieben können. Jetzt macht’s der Compiler von sich aus.

Oliver

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das mag sein, hier arbeitet vermutlich "rohdata_flash" ordentlich was 
ab. Für serielle Debugausgaben verwende ich überall das F Makro 
ansonsten auch constexpr/constinit. Der Compiler sieht da wohl noch viel 
viel mehr. Ich kann kaum glauben das ich 1kB als nicht konstante 
Variablen liegen gelassen habe. Aber erstmal egal, ich finde das gut. 
Ist ein Zeichen das es funktioniert. :-)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Trotz 1k weniger "RAM Belegung"

Zumindest teilweise entfällt das wohl auf Vtables? Aber 1k wär dann doch 
recht viel. Blick ins Map-File bringt Aufschluss.

Interessant wäre auch ein Vergleich mit v8, der dürfte kleineren Code 
produzieren als alle v9+.

von Georg P. (perthil)


Lesenswert?

Hallo,

Ich benutze MPLAB-X mit der Gcc Toolchain von Microchip. Von denen gibt 
es ja nur einen avr-gcc mit Version 7.3.0.

Ich würde gern Mal was neueres probieren. Deshalb ein paar Fragen.

Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?

Wenn nein, wie kann man den sonst in MPLAB X einbinden?

Ich habe bis jetzt nur die Quellen gefunden, muss man den dann
selber übersetzen? Wird da die Toolchain dann auch mit erzeugt?

Ich würde das auch selber übersetzen, aber am Ende suche ich dann wieder
irgendwelche fehlenden Libraries, die ich dann doch nicht benutzen kann,
weil 22.04LTS noch eine alte Version benutzt, und die neue nicht mehr 
kompatibel ist. Das ist mir so oder so ähnlich schon mehrfach passiert.
Also verplempere ich meine Zeit auf irgendwelchen 
Nebenkriegsschauplätzen anstatt mit meinen eigentlichen Projekten 
voranzukommen,

P.S. MPLAB-X benutze ich nur weil man damit debuggen kann. Ich würde 
auch lieber eine andere IDE benutzten, aber nur, wenn das debuggen über 
UPDI und mit den Adaptern von Microchip (snap) damit geht. So etwas wie 
Geany würde mir als IDE reichen.

Danke schon Mal,

VG

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Auf gcc.gnu.org gibt's nur Quellen. Builds gibt's zum Beispiel bei Zak 
Kemble

https://github.com/ZakKemble/avr-gcc-build?tab=readme-ov-file#avr-gcc

Die AVR-LibC Dokumentation beschreibt wie man die Tools generieren kann.

https://www.nongnu.org/avr-libc/user-manual/install_tools.html

Diese Version v2.1 der Anleitung müsste allerdings mal überarbeitet 
werden.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Georg P. schrieb:
> Ich würde gern Mal was neueres probieren. Deshalb ein paar Fragen.
>
> Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?

Wenn du generell an neuen Dingen interessiert bist, könntest du mal Arch
Linux ausprobieren. Hab's gerade upgedatet und siehe da:
1
$ avr-gcc --version
2
avr-gcc (GCC) 14.1.0
3
Copyright (C) 2024 Free Software Foundation, Inc.
4
This is free software; see the source for copying conditions.  There is NO
5
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

von Vincent H. (vinci)


Lesenswert?

Cortex-M4 Projekt (Modellbahn-Decoder):
GCC13 - 156kB
GCC14 - 150kB

von Monk (roehrmond)


Lesenswert?

Die neue Version gibt es bestimmt bald bei Zak
https://blog.zakkemble.net/avr-gcc-builds/

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

@ Johann:
Mit gcc 8 kann ich das nicht mehr kompilieren.

Wonach muss man in den .map Dateien suchen?

@ Georg:
Den avr-gcc 14.1.0 kann ich dir geben, dass ist nicht das Problem. Außer 
du möchtest das selbst bauen. Die eigentliche Frage lautet jedoch wie 
man das in MPLAB-X einbindet. Da wird auch keine Installation auf OS 
Ebene helfen, nehme ich stark an, weil die IDE ihre Toolchain mitbringt. 
In Microchip Studio ist es relativ einfach. Man muss einen neuen Eintrag 
anlegen und den Pfad bis zum 1. bin Verzeichnis konfigurieren. Ob das in 
MPLAB-X ähnlich einfach ist weiß ich nicht. Kannst das auch mit der 
13.2.0 von Zak Kemble ausprobieren.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Mit gcc 8 kann ich das nicht mehr kompilieren.

Verwendest du bleeding edge C++, oder was geht da schief?

> Wonach muss man in den .map Dateien suchen?

In v14 schauen was in Output Section .rodata landet. Evtl. funktioniert 
auch diff gegen v13.

von Georg P. (perthil)


Lesenswert?

@Veit

Danke, aber im Moment habe ich keine Zeit mehr.

Selber kompilieren habe ich probiert, er findet aber 3 Libraries nicht. 
Alle drei sind aber installiert, 2 davon viel neuer als gefordert und 
eine älter.

Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert. 
Sie ließ sich ähnlich einfach wie im Microchip Studio einbinden, brachte 
aber dann beim Übersetzen Fehler. Dem Compiler fehlte die passende 
glibc.
Die gabs aber wieder Mal nur als Source...

Ich warte Mal, bis es Ubuntu 24.04.1 LTS gibt. Eventuell gibt es dann 
auch den avr-gcc 14.1 vom Zak. Dann probiere ich es nochmal.

Vielen Dank euch allen.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich bin wahrscheinlich ein hunds­mi­se­ra­bler Programmierer. Ich 
versuche schon C++ zu schreiben mit "moderaten" Vorteilen neuer 
Sprachfeatures die ich verstehe. Der 8er hat Probleme mit dem Datentyp 
'auto' so wie ich es verwende. Template Objekte mittels 'auto' Referenz 
an Funktionen übergeben. Habe nochmal andere Programme probiert mit dem 
avr-gcc 8.5.0 zu kompilieren. Jedoch bricht die Kompilierung auch hier 
immer ab. Entweder mit:
1
avr/bin/ld.exe: --relax and -r may not be used together
2
avr/bin/ld.exe: error: lto-wrapper failed
oder kombiniert mit:
1
warning: use of 'auto' in parameter declaration only available with -fconcepts
Nur wenn mir mit neueren Toolchains ab 9+ nicht einmal eine Warnung 
angezeigt wird, kann es so falsch nicht sein was ich schreibe. Es kann 
natürlich sein das es generell nicht optimal ist, gebe ich gern zu. 
Hatte mir Wilhelm schon einmal gesagt. Das soll aber jetzt kein 
Programmierthread werden. ;-) Ich arbeite daran.

Bin auf 2 ältere Programme für den ATmega2560 ausgewichen. Nur hier kann 
der 14er nicht punkten mit rohdata_flash. Die Ergebnisse sind 
durchwachsen. Mit Prog 2 ist der 13er sogar vorn. Also es kommt darauf 
an. Es kommt bestimmt auch darauf an wie gut man programmiert, also was 
man dem Compiler überhaupt serviert. Da will ich mal gar nicht meckern. 
:-)
1
avr-gcc      Prog 1         Prog 2
2
 7.5.0 ... 5110 / 401 ... 8176 / 373  // Bytes Flash / RAM, C++17, Os
3
 8.5.0 ... 5128 / 401 ... 8130 / 373  // " --- "
4
 9.5.0 ... 5196 / 401 ... 8856 / 373
5
10.5.0 ... 5238 / 401 ... 8770 / 373
6
11.4.0 ... 5242 / 401 ... 8758 / 373
7
12.3.0 ... 5202 / 401 ... 8118 / 373
8
13.2.0 ... 5250 / 401 ... 8094 / 373
9
14.1.0 ... 5260 / 401 ... 8592 / 373
.map Files schau ich mir an ...

von Alexander S. (alesi)


Lesenswert?

Georg P. schrieb:
> Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?

gcc-avr ist bei Debian leider schon lange verwaist (orphaned), d.h. es 
gibt keinen Betreuer (maintainer) für das Paket. Siehe
 gcc-avr: Package version severely outdated compared to main 
gcc-toolchain
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989

von Monk (roehrmond)


Lesenswert?

Alexander S. schrieb:
> gcc-avr ist bei Debian leider schon lange verwaist (orphaned), d.h. es
> gibt keinen Betreuer (maintainer) für das Paket.

Alles halb so wild, der avr-gcc in der XC8 Toolchain von Microchip ist 
genau so alt.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das diff File wäre 2MB groß, weil fast alles verschieden ist.
Nur nach .rohdata suchen lassen:
1
errno               |0080486c|   B  |            OBJECT|00000002|     |.bss
2
__bss_end           |0080486e|   B  |            NOTYPE|        |     |.bss
3
_end                |0080486e|   B  |            NOTYPE|        |     |.bss
4
__eeprom_end        |00810000|   R  |            NOTYPE|        |     |.rodata
5
__RODATA_VMA__      |00a00000|   A  |            NOTYPE|        |     |*ABS*
6
.LC76               |00a08000|   r  |            NOTYPE|        |     |.rodata
7
__RODATA_ORIGIN__   |00a08000|   A  |            NOTYPE|        |     |*ABS*
8
__rodata_start      |00a08000|   A  |            NOTYPE|        |     |*ABS*
9
.LC84               |00a08010|   r  |            NOTYPE|        |     |.rodata
10
vtable for HardwareSerial|00a0803a|   r  |            OBJECT|00000012|     |.rodata
11
vtable for TwoWire  |00a0804c|   r  |            OBJECT|00000012|     |.rodata
12
digital_pin_to_bit_mask|00a0805e|   r  |            OBJECT|00000037|     |.rodata
13
digital_pin_to_port |00a08095|   r  |            OBJECT|00000037|     |.rodata
14
digital_pin_to_bit_position|00a080cc|   r  |            OBJECT|00000037|     |.rodata
15
LED_HELLIGKEIT::led10mA|00a08103|   r  |            OBJECT|0000010c|     |.rodata
16
__rodata_end        |00a08493|   A  |            NOTYPE|        |     |*ABS*

led10mA ist ein constexpr unsigned int Array mit 134 Werte, macht 268 
Bytes. Der Rest sind Funktionen der Arduino IDE. rohdata belegt im Flash 
Adressen von 0xA08000 bis 0xA08493 was in Summe 493  Bytes sind. Das 
wäre die Hälfte vom wegoptimierten 1k RAM.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

.rodata belegt 0x493 = 1171 Bytes.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Moin,

ähm ja, ich versinke gerade im Stuhl. :-)
Danke.

von Wilhelm M. (wimalopaan)


Lesenswert?

Du vergleichst hier auch Äpfel mit Birnen: einmal ein AVR128 und dann 
einen AtMega 2650. Denn der AVR128 kann rodata-flash-mapping:

https://gist.github.com/sprintersb/7e538928f5b481961d31458d2e5a402d

Und wenn Du das benutzt:

Veit D. schrieb:
> das mag sein, hier arbeitet vermutlich "rohdata_flash" ordentlich was
> ab.

sehen die Ergebnisse eben so wahrscheinlich aus.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe noch ein Programm auf der Platte gefunden was auch mit dem 
avr-gcc 7 kompiliert. Aber wieder nicht mit dem 8er. Der 8er hat einen 
Bug. Und die Option rohdata abschalten funktioniert auch nicht wie ich 
festgestellt habe. Dann dachte ich vielleicht wurde in der Doku die 
Optionen der Devices verwechselt, aber es spielt keine Rolle. rohdata 
wird nicht abgeschalten.
1
avr-gcc      Prog 3   (mit AVR128DB64)
2
 7.5.0 ... 20928 / 1969 // Bytes Flash / RAM, C++17, Os, flto
3
 8.5.0 ...      N/A     // " --- "
4
 9.5.0 ... 21084 / 1997 
5
10.5.0 ... 20674 / 1997
6
11.4.0 ... 20578 / 1997
7
12.3.0 ... 20554 / 1997
8
13.2.0 ... 20484 / 1991
9
14.1.0 ... 20503 / 1247
10
14.1.0 ... 20503 / 1247  // " --- " und 'mrodata-in-ram' (im .map existiert eine rohdata Section)
11
14.1.0 ... 20503 / 1247  // " --- " und 'mno-rodata-in-ram' (im .map existiert eine rohdata Section)

8er Version: Problem des Linkers. Egal ob mit oder ohne -mrelax Option.
1
c:/avrtoolchain/avr-gcc-8.5.0_mingw32_binutils2.40_avrlibc2.1github/bin/../lib/gcc/avr/8.5.0/../../../../avr/bin/ld.exe: --relax and -r may not be used together
2
collect2.exe: error: ld returned 1 exit status
3
lto-wrapper.exe: fatal error: C:\avrToolchain\avr-gcc-8.5.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/avr-gcc returned 1 exit status
4
compilation terminated.
5
c:/avrtoolchain/avr-gcc-8.5.0_mingw32_binutils2.40_avrlibc2.1github/bin/../lib/gcc/avr/8.5.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed
6
collect2.exe: error: ld returned 1 exit status

Gibt es dafür einen Patch?

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?

Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen? 
Sowas wie
1
%{!r:LINK_RELAX_SPEC}

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Johann L. schrieb:
> D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?

Richtig, soweit ich das feststellen konnte.
1
14.1.0 ... 20503 / 1247 // ohne diese Option
2
14.1.0 ... 20503 / 1247 // -mno-rodata-in-ram
3
14.1.0 ... 20503 / 1247 // -mrodata-in-ram
Laut meiner Ansicht ist es unwahrscheinlich das die Codegröße gleich 
bleibt und es dürfte im .map File keine rohdata Section geben.

> Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen?
> Sowas wie
>
1
%{!r:LINK_RELAX_SPEC}

Danke, ich versuche es.

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Hallo,
>
> Johann L. schrieb:
>> D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?

Die section rodata im map-file / assembler-file ist immer da, jedoch 
wird unterschiedlich platziert. Bei Verwendung der flash-Einblendung 
liegt sie viel weiter oben, z.B. bei 0x00a08000 statt bei 0x00804000

P.S.: Die setion heisst rodata (read-only) und nicht rohdata ;-)

Wenn das nicht der Fall ist bei Dir, dann zeige mal Dein Programm und 
den Compiler-Aufruf.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Wilhelm M. schrieb:
> Die section rodata im map-file / assembler-file ist immer da,

Auf Assembler-Ebene gibt es nur Input Sections, und die werden nicht 
lokatiert.

Lokatiert werden nur Output Sections. Eine .rodata Output Section gibt 
es nur für Emulations avrtiny, avrxmega3, avrxmega2_flmap und 
avrxmega4_flmap. Die beiden letzten werden angewählt mit 
-mno-rodata-in-ram (default).

von Wilhelm M. (wimalopaan)


Lesenswert?

Johann L. schrieb:
> Wilhelm M. schrieb:
>> Die section rodata im map-file / assembler-file ist immer da,
>
> Auf Assembler-Ebene gibt es nur Input Sections, und die werden nicht
> lokatiert.

Genau: wie gesagt, im Assembler-file ist die .rodata-section (input) 
immer da (bei den entsprechenden Architekturen).

> Lokatiert werden nur Output Sections. Eine .rodata Output Section gibt
> es nur für Emulations avrtiny, avrxmega3, avrxmega2_flmap und
> avrxmega4_flmap. Die beiden letzten werden angewählt mit
> -mno-rodata-in-ram (default).

Im map-file ist diese auch immer da, liegt natürlich jeweils woanders 
bzw. wird nicht benutzt.

Und ich denke, dass ist das, was er hier feststellt (zumindest, wenn er 
einfach nach .rodata grep-ed und einen match erhält):

Veit D. schrieb:
> 14.1.0 ... 20503 / 1247  // " --- " und 'mrodata-in-ram' (im .map
> existiert eine rohdata Section)
> 14.1.0 ... 20503 / 1247  // " --- " und 'mno-rodata-in-ram' (im .map
> existiert eine rohdata Section)

Beispiel mit rodata im RAM:

.rodata        0x00804000       0xc8 /tmp/ccFWXQb4.o

Beispiel mit rodata gemapped:

.rodata        0x00a08000       0xc8 load address 0x00018000

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Veit D. schrieb:
> Hallo,
>
> Johann L. schrieb:
>
>> Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen?
>> Sowas wie
>>
1
%{!r:LINK_RELAX_SPEC}

Habe mir das Spec-File vom AVR128DB64 angeschaut. Es gibt 2 Einträge.
1
*asm_relax:
2
  %{mrelax:--mlink-relax} 
3
4
*link_relax:
5
  %{mrelax:--relax}
Ich weiß nicht was ich ändern muss. Internetsuche blieb auch erfolglos.

----------------------------------------------------------

Kompiliert wird mit:
1
-c -g -Os -Wall -Wextra -std=gnu++20 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -Wno-volatile

24335 / 2158 Bytes // ohne weitere Option
24335 / 2158       // zusätzlich -mno-rodata-in-ram

.map Dateien sind gleich.

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Kompiliert wird mit:-c -g -Os -Wall -Wextra -std=gnu++20 -fno-exceptions
> -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics
> -Wno-error=narrowing -MMD -flto -Wno-volatile
>
> 24335 / 2158 Bytes // ohne weitere Option
> 24335 / 2158       // zusätzlich -mno-rodata-in-ram
>
> .map Dateien sind gleich.

Dann solltest Du kontrollieren, ob das Flag -mrodata-in-ram tatsächlich 
verwendet wird, oder ob Du mit den map-files durcheinander gekommen 
bist.

Ach, jetzt sehe ich es: Du musst -mrodata-in-ram angeben. Die Wirkung 
des Flags ist andersherum, als Du denkst.

: Bearbeitet durch User
von Ein T. (ein_typ)


Angehängte Dateien:

Lesenswert?

Yalu X. schrieb:
> Wenn du generell an neuen Dingen interessiert bist, könntest du mal Arch
> Linux ausprobieren. Hab's gerade upgedatet und siehe da:
>
>
1
> $ avr-gcc --version
2
> avr-gcc (GCC) 14.1.0>

Arch Linux ist ohnehin in vielerlei Hinsicht eine feine Sache, 
allerdings befürchte ich, daß nicht jeder seine gut eingefahrene 
Linux-Installation ersetzen möchte oder kann.

Deswegen habe ich im Anhang eine kleine Demo zusammengestellt, mit deren 
Hilfe Arch Linux mit den Paketen avr-gcc, avr-libc und make einfach mit 
Hilfe eines Docker-Image nutzen läßt. Mit dem Skript build.sh wird 
automatisch ein Image mit den genannten Paketen aus dem Dockerfile 
erstellt. Die Skripte run*.sh zeigen, wie das Image benutzt werden kann.

Ein Sonderfall ist das Skript "run.sh", dem das gewünschte Kommando 
einfach auf der CLI übergeben werden kann, wie im Folgenden gezeigt. 
Dieses Skript kümmert sich dann darum, das Unterverzeichnis *src/* ins 
Verzeichnis */build* des Containers zu mounten, das Kommando interaktiv 
im Vordergrund auszuführen ("-it") und den Container nach dem Aufruf 
automatisch löschen ("--rm").
1
./run.sh make compile

Im Unterverzeichnis gibt es ein kleines C-Programm aus dieser [1] 
Quelle.

Kleiner Wermutstropfen: die Kommandos im Container laufen als Benutzer 
root und deswegen gehört auch die erzeugte "main.elf" natürlich root. 
Das kann der geneigte Benutzer aber recht einfach ändern, indem er im 
Here-Dokument von "RUN" mit useradd(8) einen neuen Benutzer mit der 
eigenen UID anlegt und dem Dockerfile am Ende die Direktive "USER" 
hinzufügt, hier den Benutzer "build" mit (meiner) UID 1000:
1
FROM archlinux:base
2
RUN <<EOS
3
    useradd --uid 1000 --no-create-home --home-dir /build build
4
    pacman --sync --refresh --noconfirm avr-gcc avr-libc make
5
    mkdir /build
6
EOS
7
WORKDIR /build
8
VOLUME /build
9
USER build

Nebenbei bemerkt, lassen sich auf diese Weise beliebige 
Linuxdistributionen mit den darin enthaltenen Paketen und Paketversionen 
nutzen. Mit ein wenig mehr Arbeit ist es sogar möglich, GUI-Programme 
(wie bei mir Google Chrome) mit Docker zu benutzen. Dazu sei auf das 
Github-Repository der bezaubernden Jessica Frazzelle unter [2] 
verwiesen. Deren Dockerfiles laufen zwar unter irgendetwas RedHat-igem, 
sind aber leicht für Debian-basierte anpaßbar.

Für Fragen und Ideen stehe ich gerne zur Verfügung, HTH und viel Spaß! 
:-)


[1] https://www.micahcarrick.com/getting-started.html
[2] https://github.com/jessfraz/dockerfiles

von Veit D. (devil-elec)



Lesenswert?

Hallo,

es ist egal welche Option oder keine Option man verwendet. Man erhält 
immer das gleiche Ergebnis. Den Rest nennt man Plausibilitätsprüfung. 3 
Möglichkeiten liefern das gleiche Ergebnis. Das kann nicht sein.

Habe es nochmal kompilieren lassen. Erneut gleiche Ergebnisse.
1
-c -g -Os -Wall -Wextra -std=gnu++20 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -Wno-volatile

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Die Option hat keine Wirkung aufs Compilieren oder Assemblieren, sondern 
nur aufs Linken. Wenn die erzeugen Dateien nicht vom Makefile abhängen, 
braucht's vorm Linken ein  make clean.

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> es ist egal welche Option oder keine Option man verwendet

Nö, irgendetwas machst Du falsch. Wie oben schon geschrieben:

1) Du hast die Wirkung der Optionen vertauscht

2) Ggf. hast Du das Compilieren bzw. Linken vergessen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
1
> avr/bin/ld.exe: --relax and -r may not be used together
2
> avr/bin/ld.exe: error: lto-wrapper failed

Das Problem kann ich jetzt nicht nachvollziehen; etwa Linken mit -mrelax 
-flto und alles funktioniert problemlos mit v8.

Verwendest Du Arduino, oder wo kommt das -r her?

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

ich verwende aktuell die Arduino IDE. Mir fiel bis zu diesen 
Vergleichstests hier noch nie auf das die 8er Probleme machen würde. 
Vielleicht wiederhole ich die Vergleichstest nochmal mit dem 
Microchip-Studio. Abgesehen davon, wenn die 7er und die 9er+ 
funktionieren, warum dann ausgerechnet die 8er nicht.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Abgesehen davon, wenn die 7er und die 9er+
> funktionieren, warum dann ausgerechnet die 8er nicht.

Mit -r -mrelax zu Linken funktioniert bei keiner Complerversion.  Evtl. 
ist das ein Arduino Problem, dass beim Bauen von Libs (Arduino macht ja 
alles mit Static Linbs) -r -mrelax (oder -r Wl,--relax) angegeben wurde.

Die Frage bleibt aber: Wer setzt das -r ? Das brauch man für normale, 
statische gelinkte Programme nämlich nicht.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

...eine Möglichkeit das zu umgehen ist im Specs-File:
1
*link_relax:
2
  %{!r: %{mrelax:--relax}}

von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe mit der 8er nochmal rumprobiert. Für den AVR128DB64 verwende ich 
den DxCore, also dessen Core Package. Hier kann ich mit dem 8er 
komischerweise nichts kompilieren. Warum auch immer.

Dann habe ich Programme mittels Arduino IDE für einen ATmega2560 (alles 
Arduino Standard) mit dem 8er kompilieren lassen. Hier funktioniert 
bisher alles. Also scheint es eine Einstellung vom DxCore zu sein, 
vermutlich, womit der 8er ein Problem hat. Der DxCore wird nur mit dem 
Arduino Standard avr-gcc 7.3.0 getestet und "ausgeliefert".

Dann habe ich ein Programm was für einen ATmega2560 kompiliert auf den 
AVRxDB umgezogen. Alle Hardwareabhängigkeiten natürlich entfernt. 
Kompiliert wieder nicht wegen "avr/bin/ld.exe: --relax and -r may not be 
used together". Also Core Package abhängig.

Wo das -r herkommen soll sehe ich jedoch nicht. Ich sehe:
1
C:\\avrToolchain\\avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.2GitHub/bin/avr-gcc" -Wall -Wextra -Os -g -flto -fuse-linker-plugin -mrelax -Wl,--gc-sections,--section-start=.text=0x200,--section-start=.FLMAP_SECTION1=0x8000,--section-start=.FLMAP_SECTION2=0x10000,--section-start=.FLMAP_SECTION3=0x18000 -mmcu=avr128db64 -o
also nur -mrelax und kein -r alleine.

Die 2 Zeilen von 18:07 Uhr habe ich im device-specs File 
"specs-avr128db64" wie folgt eingefügt, zeigt jedoch keine Wirkung. 
Gleiche Fehlermeldung.
1
*asm_errata_skip:
2
  %{!mskip-bug: -mno-skip-bug}
3
4
*link_pmem_wrap:
5
6
7
*link_relax:
8
  %{mrelax:--relax} 
9
10
*link_relax:
11
  %{!r: %{mrelax:--relax}}
12
13
*link_arch:
14
  %{mmcu=*:-m%*} 
15
16
*link_data_start:
17
  %{!Tdata:-Tdata 0x804000}
18
19
*link_text_start:
20
21
22
*self_spec:
23
  %<mmcu=* -mmcu=avrxmega4 %<mshort-calls %<msp8

Nochmal die Arduino typische platform.txt Datei angeschaut und 
durchsuchen lassen. Darin werden alle Parameter für die Kompilierung 
zusammengebaut. Es gibt kein einziges '-r' in der gesamten Datei, wenn 
dann '-mrelax', also genauso wie ich es in der vollständigen Ausgabe 
sehe.

Rudi Ratlos.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
>
1
> *link_relax:
2
>   %{mrelax:--relax}
3
> 
4
> *link_relax:
5
>   %{!r: %{mrelax:--relax}}
6
> 
7
>

Das definiert die link_relax Spec 2x. Nimm die erste Definition raus und 
ersetze sie durch die zweite.

Das wirks aber nur, wenn -r angegeben wird: Die Spec bedeutet: Wenn kein 
-r angegeben ist und wenn -mrelax angegeben ist, dann linke mit 
--relax.

Versuch mal -v und -Wl,-v anzugeben um rauszufunden, wo das -r herkommt.

von Veit D. (devil-elec)



Lesenswert?

Hallo,

Danke. Spec File korrigiert.
1
*asm_errata_skip:
2
  %{!mskip-bug: -mno-skip-bug}
3
4
*link_pmem_wrap:
5
6
7
*link_relax:
8
  %{!r: %{mrelax:--relax}}
9
10
*link_arch:
11
  %{mmcu=*:-m%*} 
12
13
*link_data_start:
14
  %{!Tdata:-Tdata 0x804000}
15
16
*link_text_start:
17
18
19
*self_spec:
20
  %<mmcu=* -mmcu=avrxmega4 %<mshort-calls %<msp8

Immer noch Fehler.
avr/bin/ld.exe: --relax and -r may not be used together

Mit Optionen siehe Anhängen. Ich kann beim besten Willen kein -r finden.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Ich kann beim besten Willen kein -r finden.

Weil der Build mit abgebrochen wurde mit:
1
fatal error: Wire.h: No such file or directory

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das muss ein falscher Fehler sein. Die Wire.h ist vorhanden und ohne 
Option -v funktioniert das mit den Libs. Das ist eine Standard Lib von 
Arduino, die muss funktionieren. Ich verstehe das so, dass mit Option -v 
nur in den angezeigten  6 Pfaden gesucht wird. Ohne Option -v in mehr 
Pfaden.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich mach das nochmal mit einem anderen Bsp. um Unklarheiten auszuräumen.

von Veit D. (devil-elec)



Lesenswert?

Hallo,

ohne bewusst von mir extra inkludierte Arduino Libs.
Nur
1
#include <avr/io.h>
2
#include <avr/interrupt.h>
3
#include <util/atomic.h>
Das Programm enthält nur direkte Register Programmierung.

Beitrag #7666433 wurde vom Autor gelöscht.
Beitrag #7666442 wurde vom Autor gelöscht.
von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich schreibe morgen nochmal in Ruhe einen Text was ich soeben mit 
Microchip Studio getestet habe. Sorry.

von Michael D. (nospam2000)


Lesenswert?

Ein T. schrieb:
> Kleiner Wermutstropfen: die Kommandos im Container laufen als Benutzer
> root und deswegen gehört auch die erzeugte "main.elf" natürlich root.

Um die Userid nicht hardcoded ins Dockerfile zu schreiben kann man sie 
beim Aufruf von docker mitgeben:
1
docker run -u "$(id -u):$(id -g)" ...

damit gehören alle erzeugten Dateien dem aufrufenden User.

 Michael

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

> Ich verstehe das so, dass mit Option -v nur in den
> angezeigten  6 Pfaden gesucht wird. Ohne Option -v
> in mehr Pfaden.

Natürlich ist das wie es geschrieben steht Blödsinn. -v erzeugt nur die 
Debugausgaben unabhängig von allen anderen. Nur warum kommt die 
Fehlermeldung mit der nicht gefundenen Wire.h erst mit der Debugausgabe? 
Zudem der Fehler wie gesagt nicht sein kann. Der Fehler ist wirklich 
Blödsinn. Die Wire.h muss wie alles andere gefunden werden. Wenn die 
8.5.0 Toolchain plötzlich keine fremden Libs mehr findet wäre das 
komischer als angenommen.

Ich habe mittlerweile 3 verschiedene Toolchains gebaut.
a) avr-gcc-8.5.0_mingw32_binutils2.40_avrLibc2.1GitHub
b) avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.1GitHub
c) avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.2GitHub
Die Unterschiede erkennt man im Namen.
Letztere hat das geänderte Spec File für den AVR128DB64, wegen mrelax.

Ich verwende jetzt ein ganz simples Programm, siehe main.cpp und das 
Microchip Studio.

a) cannot find LINK_RELAX_SPEC: No such file or directory
b) kein Fehler, nur andere binutils Version
c) kein Fehler, andere avrLibC Version + Spec File Patch

Dann habe ich noch ein anderes Programm mit eigenen Libs mit Microchip 
Studio getestet. Beackert die USARTs. Der Lib Pfad ist in den 
Projekeinstellungen angegeben. Das kompiliert überraschenderweise mit 
allen 3 Varianten fehlerfrei.

Ich fasse einmal zusammen. Die 8er verhält sich anderes als Andere. 
Irgendwie zickig. Der Relax-Fehler ist Umgebungsabhängig und 
Programmabhängig.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

LINK_RELAX_SPEC ist nur ein Macro in den Compiler QUELLEN.  Im 
Specs-File steht natürlich nur der Wert des Macros.
1
#define LINK_RELAX_SPEC                         \
2
  "%{mrelax:--relax} "

Stattdessen
1
#define LINK_RELAX_SPEC                         \
2
  "%{!r: %{mrelax:--relax}} "

zu verwenden würde IMO aber nur einen Anwenderfehler verdecken.  Ich 
sehe immer noch nicht, wo -r --relax herkommt.

Weder in a) noch in b) oder c) taucht "relax" auf.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

so wie es aussieht kann ich verschiedene Testbedingungen schaffen und 
komme immer auf unterschiedliche Ergebnisse. Es kristallisiert sich 
leider nicht die eine Toolchain der 8er heraus. Womit man dann ganz 
gezielt "arbeiten" könnte.

Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir 
ziemlich sicher. Die kommt scheinbar aus dem Nichts.  ;-)

Aktuell kommen wir hier nicht weiter wie es aussieht. Wir lassen erstmal 
das Wochenende und Feiertag vergehen. Dann sehen wir vielleicht weiter.
Ich wünsche dir erstmal ein ruhiges Wochenende. Haste dir verdient.

: Bearbeitet durch User
von Martin H. (horo)


Lesenswert?

Veit D. schrieb:
> Die 8er verhält sich anderes als Andere.
> Irgendwie zickig.

Das habe ich auch schon festgestellt, siehe meine Anmerkung in 
Down-Under:
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5495680/#msg5495680

von Wilhelm M. (wimalopaan)


Lesenswert?

Martin H. schrieb:
> Veit D. schrieb:
>> Die 8er verhält sich anderes als Andere.
>> Irgendwie zickig.
>
> Das habe ich auch schon festgestellt, siehe meine Anmerkung in
> Down-Under:
> 
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5495680/#msg5495680

Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler? 
Lasst ihn in Frieden sterben ...

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo Martin,

das ist Detailwissen wo ich nicht mitreden kann.

Hallo Johann,

ich habe mit der Arduino IDE und dem DxCore noch eins probiert.
Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist.
Siehe da, es kompiliert.
Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax 
zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt 
wird. Hilft das weiter? Du sollst dennoch dein Wochenende genießen.  ;-)

: Bearbeitet durch User
von Martin H. (horo)


Lesenswert?

Wilhelm M. schrieb:
> Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler?
> Lasst ihn in Frieden sterben ...

Der 8er baut halt kleinere Binaries als die folgenden, erst der 13er kam 
wieder in diese Dimensionen zurück. Und das zählt z.B. für den 
Transistortester, dessen Flash immer mehr aus allen Nähten platzt.

https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5054215/#msg5054215

https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5150607/#msg5150607

Außerdem ist selbst der 8er deutlich „moderner“ als das, was es bei 
Debian (incl. SID) gibt :(

Beitrag "Re: GCC v14 Release"

von Wilhelm M. (wimalopaan)


Lesenswert?

Martin H. schrieb:
> Wilhelm M. schrieb:
>> Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler?
>> Lasst ihn in Frieden sterben ...
>
> Der 8er baut halt kleinere Binaries als die folgenden, erst der 13er kam
> wieder in diese Dimensionen zurück. Und das zählt z.B. für den
> Transistortester, dessen Flash immer mehr aus allen Nähten platzt.
>
> 
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5054215/#msg5054215
>
> 
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5150607/#msg5150607
>
> Außerdem ist selbst der 8er deutlich „moderner“ als das, was es bei
> Debian (incl. SID) gibt :(
>
> Beitrag "Re: GCC v14 Release"

Ja, klar, es gibt immer wieder alte Projekte, wo das dann durch immer 
mehr features zum Problem wird. Allerdings ist dieses 
Komponententesterprojekt auch für größere atmegas wie z.B. m1284.
Ich habe mir das Projekt nicht genau angeschaut, aber da würde ich 
einfach daran gehen, einpaar Sachen als Compiletime-Option abschaltbar 
machen.

Allerdings: dieser Fehler im ISR-Vector ist schon krass bei 8.3.

Naja, Debian als Entwicklerplattform ist schon recht ... konservativ ;-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist.
> Siehe da, es kompiliert.
> Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax
> zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt
> wird.

Aber irgendwo wird doch -r gesetzt? Oder ist das ein Linkler-Bug? Das 
-r kommt doch vermutlich von der Arduino IDE beim Bauen von Libs?

> Hilft das weiter?

Nicht wirklich. Ich verstehe immer noch nicht ob das ein Bug in den 
Tools ist (und wie der zu fixen wäre), ein Bug in Arduino oder ein 
Anwenderfehler.

> Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir
> ziemlich sicher. Die kommt scheinbar aus dem Nichts.  ;-)

würde ja bedeuten, dass es ein Bug in den Tools ist, etwa beim 
Verarbeiten der Linker-Optionen oder in den LTO Specs.

Wilhelm M. schrieb:
> Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler?

Weil die v8 besser ist als alles, was danach kommt.  Sie ist gut genut, 
dass ich meine eigene v8.5.1 maintaine, wo paar Probleme die erst später 
gefixt wurden rückportiert wurden, wie PR92606, PR101188.  Und Probleme 
wie mit PR90706 und PR110093 hat man mit v8 eben nicht.

von Wilhelm M. (wimalopaan)


Lesenswert?

Johann L. schrieb:
> Weil die v8 besser ist als alles, was danach kommt.

Das kommt immer auf die Anforderungen an. Für C mag das ausreichen, für 
modernes C++ nicht.

Johann L. schrieb:
> Und Probleme
> wie mit PR90706 und PR110093 hat man mit v8 eben nicht.

PR90706 kann ich im GB CE nicht nachvollziehen für >8.5

Wenn man PR110093 als template-code schreibt, wird es optimal wie in 8.5

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

Johann L. schrieb:
> Veit D. schrieb:
>> Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist.
>> Siehe da, es kompiliert.
>> Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax
>> zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt
>> wird.
>
> Aber irgendwo wird doch -r gesetzt? Oder ist das ein Linkler-Bug? Das
> -r kommt doch vermutlich von der Arduino IDE beim Bauen von Libs?

Ich gebe mein Bestes den Ursprung zu finden. Was ich wohl sicher 
behaupten kann ist, dass es auch ein Problem mit der Option -v gibt. 
Egal für welchen Controller ich mit der Arduino IDE kompiliere. Ob für 
Standard ATmega2560 oder den ATmega4809. Beim ATmega4809 ist auch egal 
ob ich dafür das megaavr Arduino Core Package oder das MegaCoreX Core 
Package von mcudude verwende. Ist in allen Umgebungen die -v Option 
aktiv werden Libs nicht gefunden. Nehme ich die Option -v raus, 
kompiliert alles. Das kann ja eigentlich auch nicht sein. Entweder 
können sie gefunden werden oder nicht, völlig unabgängig der Option -v.

>> Hilft das weiter?
>
> Nicht wirklich. Ich verstehe immer noch nicht ob das ein Bug in den
> Tools ist (und wie der zu fixen wäre), ein Bug in Arduino oder ein
> Anwenderfehler.
>
>> Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir
>> ziemlich sicher. Die kommt scheinbar aus dem Nichts.  ;-)
>
> würde ja bedeuten, dass es ein Bug in den Tools ist, etwa beim
> Verarbeiten der Linker-Optionen oder in den LTO Specs.

Das Problem ist für mich auch noch zu vielfältig. Unter bestimmten 
Umständen findet er keine Libs. Könnte man behaupten das ist ein Arduino 
Problem. Auf der anderen Seite gibt es einen Umstand mit Microchip 
Studio wo der relax Fehler auftritt. Da ist nun weit und breit nichts 
von Arduino im Spiel. Für mein Gefühl sind da mehrere Probleme 
vorhanden.

Ich bau im Moment Toolchains mit allen avr-gcc 8 Versionen. Mal sehen ob 
das Problem ab einer bestimmten Version beginnt. Vielleicht kann man 
sich so dem Problem nähern.

Ansonsten, wenn ich nichts mehr dazu beitragen kann, außer vielleicht 
testen, könntest du dich vielleicht mit mcudude auf Entwickler Niveau 
unterhalten. Ihr müßtest euch ja kennen. Er verwendet Arduino und seinen 
MegaCoreX.

Das Einzigste was ich mache um andere Toolchains zu verwenden ist eine 
platform.local.txt erstellen und darin nur die Änderungen einzutragen. 
Alles andere steht in der platform.txt wie oben gezeigt und bleibt wie 
sie ist. Darin sehe ich keine außergewöhnlichen Optionen.
1
compiler.path=C:\avrToolchain\avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.1GitHub/bin/
2
compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++17 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto
3
compiler.cpp.extra_flags=-fno-sized-deallocation -Wall -Wextra
Das wird auch mcudude wissen wie das geht.

Ich teste nachher die Toolchains durch berichte.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> behaupten kann ist, dass es auch ein Problem mit der Option -v gibt.

-v kann ein Problem sein wenn man die Ausgabe ovn avr-gcc selbst 
braucht, etwa mit -print-multi-directory oder --version. Da bringt das 
zusätzliche Geplapper von -v die Ausgabe durcheinander.

Wilhelm M. schrieb:
> Wenn man XXX als YYY-code schreibt, wird es optimal wie in ZZZ

Es ist und bleibt aber ein Compilerproblem.

Wenn man seine Quellen verhunzen will und abhängig vom Compilerversion 
und -problem(ch)en macht, dann wird der Code ziemlich schnell unwartbar. 
Und um zu vewrifizieren, dass das Verhunzen wie gewünscht wirkt, muss 
man ständig das (Dis)assembly durchforsten.

Ich bevorzuge da die besseren Tools.

von Wilhelm M. (wimalopaan)


Lesenswert?

Johann L. schrieb:
> Wilhelm M. schrieb:
>> Wenn man XXX als YYY-code schreibt, wird es optimal wie in ZZZ
>
> Es ist und bleibt aber ein Compilerproblem.

Klaro. Das war auch als Hinweis gedacht.

> Wenn man seine Quellen verhunzen will und abhängig vom Compilerversion
> und -problem(ch)en macht, dann wird der Code ziemlich schnell unwartbar.

Wo ein solches Functionstemplate den Code verhunzt, solltest Du 
erklären. Die C++-Standardbib. verhunzt also den Code ...

Im übrigen bitte richtig zitieren.

> Und um zu vewrifizieren, dass das Verhunzen wie gewünscht wirkt, muss
> man ständig das (Dis)assembly durchforsten.

Das glaubst Du doch selbst nicht.

von Veit D. (devil-elec)


Lesenswert?

Johann L. schrieb:
> Veit D. schrieb:
>> behaupten kann ist, dass es auch ein Problem mit der Option -v gibt.
>
> -v kann ein Problem sein wenn man die Ausgabe ovn avr-gcc selbst
> braucht, etwa mit -print-multi-directory oder --version. Da bringt das
> zusätzliche Geplapper von -v die Ausgabe durcheinander.

Hallo,

das lies mir keine Ruhe. Das liegt demnach wirklich mit der Arduino 
Umgebung zusammen. Egal welche Toolchain ich verwende, sobald ich die 
Option -v verwende bricht die Kompilierung ab wegen nicht gefundener 
Lib, egal welche. Gut, dann wäre wenigstens das geklärt. Danke.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Egal welche Toolchain ich verwende, sobald ich die
> Option -v verwende bricht die Kompilierung ab wegen nicht
> gefundener Lib, egal welche.

Ok, dann geht -v nicht um an den problematischen Linker-Aufruf zu 
kommen.  Aber Arduino hat doch bestimmt einen adäquaten Ersatz, mit dem 
man die ausgeführten Befehle anzeigen lassen kann?  In den Logs die 
bislang zu sehen waren wird das ja unterschlagen.

Evtl. besser mal in nem Arduino Forum nachfragen, wie man die 
Fehlerursache eingrenzen kann?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe die Toolchains auch mit Microchip Studio getestet, mit dem gleichen 
Programm wie hier
Beitrag "Re: GCC v14 Release"

Ich kann heute mit keiner Toolchain diesen Fehler provozieren. Der ist 
einfach weg.
Device Spec File ist bei allen nicht gepatcht.
a) cannot find LINK_RELAX_SPEC: No such file or directory

Damit ist die reine AVR bzw. Microchip Studio aus dem Rennen.

Jetzt bin ich wirklich mit meinem Latein am Ende wo die -r Option 
herkommen soll im Zusammenhang mit Arduino. Der Betrachtungszustand hat 
sich damit geändert. Man sieht die -r Option nirgends, könnte dennoch 
irgendwo vorhanden sein oder irgendwo ist Voodoo im Spiel. :-) Da muss 
ich bei dem avr-gcc 8 den Spec File Patch verwenden.

Ich würde sagen wollen das WE und Feiertag ist erstmal Ruhezustand.  :-)

Grüße und bis später ...

PS: wegen -v und Arduino, da frage ich nach

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> cannot find LINK_RELAX_SPEC: No such file or directory

Da hast du irgendwo noch einen falschen Fehler reingebastelt.

von Martin H. (horo)


Lesenswert?

Johann L. schrieb:
> Weil die v8 besser ist als alles, was danach kommt.

Bis zur 12.x bin ich bei Dir, aber was ist mit Ver. 13, wo siehst Du die 
Schwächen? Die 14 ist vielleicht noch zu neu, um sie mit den anderen zu 
vergleichen.

von Harald K. (kirnbichler)


Lesenswert?

Veit D. schrieb:
> sobald ich die
> Option -v verwende bricht die Kompilierung ab wegen nicht gefundener
> Lib, egal welche.

Hier wäre es hilfreich, wenn zwischen Library und Headerdatei 
differenziert werden würde.

Denn das hast Du weiter oben schon durcheinandergebracht:

Veit D. schrieb:
> das muss ein falscher Fehler sein. Die Wire.h ist vorhanden und ohne
> Option -v funktioniert das mit den Libs. Das ist eine Standard Lib von
> Arduino, die muss funktionieren.

"wire.h" ist keine Library. Das ist eine Headerdatei, oder eine 
Include-Datei (wie auch immer man sie nennen will), aber eben keine 
Library.
Eine Library hieße im Falle des gcc "libwire.a" -- und wird beim 
Programmbau an einer völlig anderen Stelle verwendet als beim simplen 
Compilieren einzelener Sourcefiles. Mit Libraries beschäftigt sich der 
Linker.


Ja, in "C++-Sprech" und vor allem in "Arduino-Sprech" werden gerne 
Include-Dateien auch als "Library" bezeichnet, aber funktional aus 
Sicht eines Toolchainbauers ist das etwas komplett unterschiedliches.


Um auf Dein Problem mit -v zurückzukommen: Das versaut Dir aus 
irgendeinem Grund den Include-Pfad.

Hast Du Dir mal das von CMake erzeugte tatsächliche Makefile angesehen?

von Oliver S. (oliverso)


Lesenswert?

Harald K. schrieb:
> Ja, in "C++-Sprech" und vor allem in "Arduino-Sprech" werden gerne
> Include-Dateien auch als "Library" bezeichnet

Nur letzteres. C++ kennt allerdings header-only- „Libraries“, für die 
sich da keine andere Bezeichnung gefunden hat.

Oliver

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

ruhig sitzen konnte ich nun doch nicht. Kleines Update. Das nicht finden 
einer Lib mit Option -v betrifft nicht allein die 8er Toolchain. Das 
betrifft alles was mit der Arduino IDE 1.8.19 zu tun hat, egal welche 
Toolchain, auch die Default Toolchain der IDE. Man muss nur eine Lib 
zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung 
bricht ab.
Den -relax Fehler betrifft aber nur die 8er Toolchain. Muss man ganz 
schön aufpassen das getrennt zu halten.

Ein Arduino Forum User konnte das bei sich bestäigen und gab mir den 
Tipp das Flag -v nicht für .cpp sondern für .c Files zu setzen. Damit 
läuft die Kompilierung durch, auch mit -Wl,-v. In der Debugausgabe sehe 
ich nun mehrfach die gesetzte Option --mlink-relax. Ist das das Problem?

von Harald K. (kirnbichler)


Lesenswert?

Oliver S. schrieb:
> Nur letzteres. C++ kennt allerdings header-only- „Libraries“, für die
> sich da keine andere Bezeichnung gefunden hat.

Ja, richtig, nur eine sehr unglückliche Namenswahl, wenn man 
Linkerfehler und Fehler des Compilers auseinanderhalten will.

Veit D. schrieb:
> Man muss nur eine Lib
> zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung
> bricht ab.

Seufz. Worauf habe ich gerade herumgeritten, und warum?

von Veit D. (devil-elec)


Lesenswert?

Harald K. schrieb:

> Veit D. schrieb:
>> Man muss nur eine Lib
>> zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung
>> bricht ab.
>
> Seufz. Worauf habe ich gerade herumgeritten, und warum?

Weil jeder außer du weiß worum es geht. Ein Headerfile ist Bestandteil 
einer Lib. Ob die nun kompiliert ist oder nicht. Mit 
Nebenkriegsschauplätzen egal welcher Art gebe ich mich hier nicht ab. 
Das stört hier nur den Threadverlauf.

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Das stört hier nur den Threadverlauf.

Und deswegen reden wir über Arduino?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Folgender Work-Around für v8 sollte gehen:

Statt -mrelax nimmt man -Wl,--relax -Wa,--mlink-relax

Was auch geht ist -g wegzulassen.

Ist also kein Arduino Problem sondern ein Bug im Compiler (lto-wrapper).

Hätte mir eigentlich schon auffallen können, aber ich verwende normal 
nie -g.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Veit D. schrieb:
> Weil jeder außer du weiß worum es geht. Ein Headerfile ist Bestandteil
> einer Lib. Ob die nun kompiliert ist oder nicht.

Das ist Dummquatsch, denn es macht einen ganz erheblichen Unterschied 
aus, ob der Compiler irgendwas mit einer Headerdatei macht oder ob der 
Linker (das ist ein anderes Programm!) etwas mit einer Library macht.

Und wenn hier darüber diskutiert wird, daß irgendeine Option dafür 
sorgt, daß "Libs" nicht gefunden werden, dann ist dieser Unterschied 
verdammt wichtig.

Du argumentierst auf der Ebene, daß es nicht wichtig ist, ob das Auto 
nicht fährt, weil der Tank leer ist oder der Zündschlüssel fehlt.

von Veit D. (devil-elec)


Lesenswert?

Harald K. schrieb:

> Du argumentierst auf der Ebene, daß es nicht wichtig ist, ob das Auto
> nicht fährt, weil der Tank leer ist oder der Zündschlüssel fehlt.

Nein. Ich argumentiere das der Motor keinen Sprit bekommt. Das ist der 
offensichtliche Fehler. Völlig egal ob der Tank leer oder die 
Benzinpumpe defekt ist. Hat nichts mit dem Zündschlüssel zu tun, was 
eine völlig andere Fehlerursache wäre. Weil ohne Schlüssel würdest du 
erst gar nicht ins Auto kommen.  ;-)  Vergiss dein Thema nicht, können 
wir immer noch ganz am Ende klären. Aber nicht jetzt.

von 900ss (900ss)


Lesenswert?

Harald K. schrieb:
> Das ist Dummquatsch

Hüstel.....

Weshalb ist eine Headerdatei keine Library? Library darf und kann in 
unterschiedlicher Form vorliegen. Z.B Objektcode aber auch Quelltext wie 
in einer Headerdatei.

Diejenigen, die noch etwas Nachhilfe brauchen, vielleicht hier auch 
nochmal nachlesen:
https://de.m.wikipedia.org/wiki/Programmbibliothek

Eigentlich ist das hier OT.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Johann L. schrieb:
> Folgender Work-Around für v8 sollte gehen:
>
> Statt -mrelax nimmt man -Wl,--relax -Wa,--mlink-relax
>
> Was auch geht ist -g wegzulassen.
>
> Ist also kein Arduino Problem sondern ein Bug im Compiler (lto-wrapper).
>
> Hätte mir eigentlich schon auffallen können, aber ich verwende normal
> nie -g.

Hallo Johann,

du bist der Beste.  :-)
Habe beide Optionen ausprobiert. Was soll ich sagen. Der relax Fehler 
ist weg. Was bleibt ist mit Option -v mit Arduino das er die Lib nicht 
findet.

Ähm, ich meine er das Headerfile nicht findet. Bevor Harald noch 
Bluthochdruck bekommt. :-)

Ich weiß jetzt nicht, ob wir das Problem weiter verfolgen? Oder ob wir 
zum noch ungeklärten Problem übergeben avr-gcc 14 und fehlendem 
mrodata-in-ram Effekt?

von Veit D. (devil-elec)


Lesenswert?

900ss schrieb:

> Eigentlich ist das hier OT.

Danke. Das ist meine Rede. Das Thema kann gern näher erörtert werden. 
Aber hier in dem Thread gibt es wichtigere Dinge als diesen 
Nebenkriegsschauplatz. Das hat schon viel zu viel Platz eingenommen. 
Harald kann dazu gern einen eigenen Thread eröffnen, worin es 
erschöpfend geklärt werden kann.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Oder ob wir
> zum noch ungeklärten Problem übergeben avr-gcc 14 und fehlendem
> mrodata-in-ram Effekt?

Dann schau Dir erstmal meinen Beitrag oben an:

Beitrag "Re: GCC v14 Release"

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Ich weiß jetzt nicht, ob wir das Problem weiter verfolgen?

Das Problem mit der Fehlermeldung vom Linker trat auf, als du Benchmarks 
für verschiedene avr-gcc Versionen gemacht hast.

Dieses Problem kann man mit -g0 (bzw. Option -g entfernen) umschiffen. 
Alternativ gibt's diesen v8 Fork: 
https://github.com/sprintersb/avr-gcc-8

> avr-gcc 14 und fehlendem mrodata-in-ram Effekt?

Der Vergleich von -mno-rodata-in-ram (default) mit -mrodata-in-ram 
sollte Unterschiede im RAM-Verbrauch zeigen, wenn

1) Device ist AVR128* oder AVR64*, und

2) Es befinden sich Daten in .rodata wie zum Beispiel vtables, und

3) Es wird avr-gcc v14+ mit Binutils v2.42+ verwendet,

was bei dir ja alles zutrifft.

Übrigens gibt es noch nen Bug in Binutils: avr-objdump -P mem-usage 
berücksichtigt keine Daten in Output Section .rodata: 
https://sourceware.org/PR31687

avr-size hingegen arbeitet korrekt, d.h. .rodata wird in der Größe von 
text berücksichtigt.

Veit D. schrieb:
> Was bleibt ist mit Option -v mit Arduino das er die Lib nicht
> findet.

Das muss ein Arduino-Ding sein.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Veit D. schrieb:
>> Was bleibt ist mit Option -v mit Arduino das er die Lib nicht
>> findet.
>
> Das muss ein Arduino-Ding sein.

...spielt aber keine Rolle mehr, weil das -v nur dazu da war, den bösen 
Aufruf zu finden, der zum Fehler führt.  Und da ist ja jetzt klar, das 
es ein Problem im LTO Wrapper war.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo Johann,

habe mich nochmal mit avr-gcc 14.1 und rodata befasst und vorher paar 
avr-gcc Vergleiche angestellt, siehe .pdf

Ih denke deine letzte Aussage zu verstehen. Nur wenn ich meine Werte 
betrachte bin ich immer noch der Meinung das entweder der Schalter 
-mrodata-in-ram nicht funktioniert oder gar avr-size.exe fehlerhaft ist.

Habe mich durch die Kommandozeile gequält. Die Werte der beiden Ausgaben 
sind untereinander im Vergleich ähnlich zu den Werten die das Microchip 
Studio ermittelt.
Mit dem Schalter -mrodata-in-ram wird nie das RAM belegt. Soll das 
wirklich so sein? Ich hatte ähnliche Werte wie beim avr-gcc-13.2 
erwartet. Wohin ist das Array verschwunden?

Die Datei main.cpp ist das letzte Testprogramm alias 
"rodataTest_avr-gcc-14" im .pdf
1
>> OHNE Flag -mrodata-in-ram kompiliert <<
2
>> avr-size.exe -d -A main.elf
3
4
main.elf  :
5
section                           size   addr
6
.text                                0      0
7
.data                                0      0
8
.bss                                 0      0
9
.gnu.lto_.profile.978610d3          11      0
10
.gnu.lto_.icf.978610d3              38      0
11
.gnu.lto_.ipa_sra.978610d3          11      0
12
.gnu.lto_.inline.978610d3           60      0
13
.gnu.lto_.jmpfuncs.978610d3         56      0
14
.gnu.lto_.pureconst.978610d3        16      0
15
.gnu.lto_.ipa_modref.978610d3       21      0
16
.gnu.lto_.lto.978610d3               8      0
17
.gnu.lto__ZL7myArray.7.978610d3   1013      0
18
.gnu.lto_main.8.978610d3           688      0
19
.gnu.lto_.symbol_nodes.978610d3     76      0
20
.gnu.lto_.refs.978610d3             25      0
21
.gnu.lto_.decls.978610d3          1340      0
22
.gnu.lto_.symtab.978610d3           20      0
23
.gnu.lto_.ext_symtab.978610d3        3      0
24
.gnu.lto_.opts                     295      0
25
.comment                            19      0
26
Total                             3700
1
>> MIT Flag -mrodata-in-ram kompiliert <<
2
>> avr-size.exe -d -A main.elf
3
4
main.elf  :
5
section                           size   addr
6
.text                                0      0
7
.data                                0      0
8
.bss                                 0      0
9
.gnu.lto_.profile.97861688          11      0
10
.gnu.lto_.icf.97861688              38      0
11
.gnu.lto_.ipa_sra.97861688          11      0
12
.gnu.lto_.inline.97861688           60      0
13
.gnu.lto_.jmpfuncs.97861688         56      0
14
.gnu.lto_.pureconst.97861688        16      0
15
.gnu.lto_.ipa_modref.97861688       21      0
16
.gnu.lto_.lto.97861688               8      0
17
.gnu.lto__ZL7myArray.7.97861688   1013      0
18
.gnu.lto_main.8.97861688           688      0
19
.gnu.lto_.symbol_nodes.97861688     76      0
20
.gnu.lto_.refs.97861688             25      0
21
.gnu.lto_.decls.97861688          1340      0
22
.gnu.lto_.symtab.97861688           20      0
23
.gnu.lto_.ext_symtab.97861688        3      0
24
.gnu.lto_.opts                     313      0
25
.comment                            19      0
26
Total                             3718

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Du linkst doch nicht etwa mit -c ?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Nicht das ich wüsste. Microchip Studio hat Defaults wie 
-ffunction-sections usw. und ich stelle zusätzlich für den Compiler "-Os 
-std=c++20 -flto -v" ein. Das Projekt ist als Cpp Projekt eingerichtet.

von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

habe es versucht auf der Kommandozeile zu kompilieren. Von Microchip 
Studio abgeschaut und bewusst Option -c rausgenommen. Scheint zu 
funktionieren. Ohne -mrodata-in-ram, also default, stimmt das mit 
Microchip Studio überein. Mit -mrodata-in-ram sehe ich eine Reaktion das 
RAM belegt wird. Soweit so gut. :-)

Jetzt frage ich mich natürlich warum Microchip Studio die Option -c 
setzt?  Ist Microchip Studio schon zu alt dafür?

 OHNE Flag -mrodata-in-ram kompiliert
 avr-size.exe -d -A main.elf
1
main.elf  :
2
section                     size       addr
3
.data                          0    8404992
4
.text                       1912          0
5
.rodata                      278   10518528
6
.comment                      18          0
7
.note.gnu.avr.deviceinfo      64          0
8
.debug_aranges                32          0
9
.debug_info                14718          0
10
.debug_abbrev              13926          0
11
.debug_line                  110          0
12
.debug_str                  6471          0
13
.debug_line_str              123          0
14
Total                      37652

 MIT Flag -mrodata-in-ram kompiliert
 avr-size.exe -d -A main.elf
1
main.elf  :
2
section                     size      addr
3
.data                        278   8404992
4
.text                       1938         0
5
.comment                      18         0
6
.note.gnu.avr.deviceinfo      64         0
7
.debug_aranges                64         0
8
.debug_info                14754         0
9
.debug_abbrev              13946         0
10
.debug_line                  257         0
11
.debug_str                  6471         0
12
.debug_line_str              123         0
13
Total                      37913

: Bearbeitet durch User
Beitrag #7668952 wurde vom Autor gelöscht.
von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Nur wenn ich meine Werte
> betrachte bin ich immer noch der Meinung das entweder der Schalter
> -mrodata-in-ram nicht funktioniert oder gar avr-size.exe fehlerhaft ist.

Du hast in Deinen Compiler-Optionen "-c" drin. D.h. es wird kein 
executable .elf erzeugt, sondern nur eine Object-Datei (die Du 
wahrscheinlich fälschlicherweise in die Datei main.elf schreibst - statt 
main.o).

Daher siehst Du auch ein .text segment der Größe 0. Das sollte Dir schon 
mal auffallen ...

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> warum Microchip Studio die Option -c setzt?

Weil das die übliche Vorgehensweise ist, ein C/C++ Projekt zu erzeugen:

Zunächst werden alle Module mit -c zu Object-Dateien *.o übersetzt. 
Hier endet der Vorgang nach dem Aufruf des Assemblers.

Dann werden alle erzeugten *.o Dateien zum *.elf Executable 
zusammengelinkt.

Wenn du sowas siehst wie:

Veit D. schrieb:
1
> main.elf  :
2
> section                           size   addr
3
> .text                                0      0
4
> .data                                0      0
5
> .bss                                 0      0
6
> .gnu.lto_.profile.978610d3          11      0

dann handelt es sich dabei um ein NICHT GELINKTES Objectfile, egal 
welcher Name der Datei verpasst wurde.  Im finalen ELF haben LTO 
Sections nämlich nix mehr zu suchen. Und dass alle Code+Data Sections 
leer sind, ist für ein fertiges ELF auch nicht der Fall.

Veit D. schrieb:
>  OHNE Flag -mrodata-in-ram kompiliert
>  avr-size.exe -d -A main.elf
1
> section                     size       addr
2
> .data                          0    8404992
3
> .text                       1912          0
4
> .rodata                      278   10518528
>  MIT Flag -mrodata-in-ram kompiliert
1
> section                     size      addr
2
> .data                        278   8404992
3
> .text                       1938         0

Das ist plausibel:

Mit -mrodata-in-ram sind die 278 Bytes an .rodata im RAM, ansonsten im 
Flash.

Ohne .rodata ist .text um 26 Bytes länger, was der Größe von 
__do_copy_data entspricht.  Dieses wird mit .rodata nicht gebraucht, 
weil .data im Beispiel leer ist.

Außerdem sieht man daran, dass im .rodata Fall nicht gegen 
__do_flmap_init gelinkt wurde, das 18 Bytes groß ist und erst in 
AVR-LibC v2.2 enthalten ist. (Dann wäre .text nur 8 Bytes größer, nicht 
26 Bytes).

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

diesmal hatte Wilhelm den richtigen Riecher.
Danke Johann mal wieder für die Erklärung.
Ich denke ich habe meinen Fehler erkannt. Ich hatte versucht die 
Kommandozeile nachzubauen und mit '-c' ein main.elf erzeugt statt 
main.o. Wenn ich die Option '-c' richtig verstehe wird mit '-c' nur 
kompiliert aber nicht gelinkt. Ohne '-c' wird kompiliert und gelinkt 
weshalb das gestern am Ende mit main.elf als Ausgabedatei funktionierte.

Noch eine Frage. Man verwendet doch eigentlich avr-g++.exe zum 
kompilieren. Ich habe  gestern die Kommandozeile mit avr-gcc.exe 
begonnen. Scheint dennoch zu funktionieren. Was macht das für einen 
Unterschied? Oder ruft avr-g++.exe sowieso avr-gcc.exe auf?

von A. B. (Firma: ab) (bus_eng)


Lesenswert?

Microchip Studio: - GCC GCC 14.1.0-x64 - erzeugt mit zak script

Microchip Studio7 compiliert mit NATIVE Compiler und installierten 
Device-Packs die modernen AVR8-uC Dx, Ex,..

Microchip Studio7 compiliert mit ZAK-AVR-GCC 14.1.0-x64-windows und 
installierten Device-Packs die modernen AVR8-uC Dx, Ex,.. NICHT.

Im Compiler-Aufruf FEHLT -B "$(PackRepoDir)\..", obwohl in 
|Project|AVR/GNU|common| der Eintrag -B "$(PackRepoDir)\.." vorhanden 
ist.

..\device-specs\specs-avr128db48
*cpp: .. -D__AVR_DEV_LIB_NAME__=avr128db48 ist deshalb NICHT definiert.


resultierende Fehlermeldungen :
- #warning "device type not defined" [-Wcpp]
   C:\Atmel-Toolchain\AVR8\avr-gcc-14.1.0-x64-windows\avr\include\avr\io.h 
633
-  cannot find crtavr128db48.o: No such file or directory

Workaround:
Nachtragen von B "$(PackRepoDir)\.. in |Compiler|Miscellaneus| UND in 
|Linker |Miscellaneus|

Weshalb -B "$(PackRepoDir)\.." mit avr-gcc-14.1.0 fehlt weiss ich nicht.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Man verwendet doch eigentlich avr-g++.exe zum kompilieren.
> Ich habe  gestern die Kommandozeile mit avr-gcc.exe begonnen.
> Scheint dennoch zu funktionieren. Was macht das für einen
> Unterschied? Oder ruft avr-g++.exe sowieso avr-gcc.exe auf?

Nein.  avr-gcc und avr-g++ rufen Sub-Programme auf anhand der übergebeen 
Dateinamen und Optionen.  Aufgerufene Programme sind zum Beispiel 
C-Compiler cc1, C++ Compiler cc1plus, LTO Compiler lto1, oder Assembler 
as.

Falls die Sprache nicht mit -x <lang> explizit angegeben wurde, werden 
folgende Datei Extensions als C++ compiliert: .cc, .cpp, .c++, .cxx, .C, 
.CPP, .cp. Als C wird .c compiliert, und als Assembler+C-Präprozessor 
wird .S und .sx behandelt.

Unterschied zwischen avr-gcc und avr-g++ ist bei den Optionen (Libs), 
die dem Linker mitgegeben werden, aber da es keine C++ Libs gibt, macht 
das kein Unterschied.

Die aufgerufenen Programme kann man mit -v anzeigen lassen, wobei die 
angezeigten Programme ihrerseits wieder andere Programme aufrufen 
können, etwa bei LTO Builds. Allerdings zeigt -v noch mehr Informationen 
an, etwa verwendete Include-Pfade.

Ein einfaches
1
avr-gcc main.c -mmcu=atmega8 -flto -v -Wl,-v
etwa zeigt folgende Programmaufrufe:
1
$prefix/libexec/gcc/$target/$version/cc1      # C-Compiler, Präprozessor
2
$prefix/$target/bin/as                        # Assembler
3
$prefix/libexec/gcc/$target/$version/collect2 # Linker Wrap
4
$prefix/$target/bin/ld                        # Linker
5
$prefix/libexec/gcc/$target/$version/lto-wrapper # Ruft LTO-Compiler
6
$prefix/libexec/gcc/$target/$version/lto1     # LTO-Compiler
7
$prefix/$target/bin/as                        # Assembler
8
$prefix/$target/bin/ld                        # Linker
Wobei
1
$prefix  = Installationspfad
2
$version = GCC Version
3
$target  = avr

Der erste Assembler-Aufruf übersetzt lediglich LTO Bytecode von ASCII 
nach Binär, weil der C-Compiler nur LTO-Bytecode erzeugt.  Der LTO-Code 
wird erst später von lto1 zum eigentlichen Assembler-Code compiliert, 
der vom 2ten Assembler-Aufruf assembliert wird.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo Johann,

Danke wieder. Ich weiß schon warum ich das einer IDE überlasse. 
Spätestens wenn zusätzliche Libs dazu kommen wird es schnell 
kompliziert. Ich werde mich damit nochmal mit einfachen Bsp. näher 
befassen müssen.

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Ich weiß schon warum ich das einer IDE überlasse.
> Spätestens wenn zusätzliche Libs dazu kommen wird es schnell
> kompliziert.

Ich denke, Du solltest Dir ein einfaches Makefile schreiben. Denn dort 
hast Du alles direkt übersichtlich an einer Stelle und kannst Dir die 
Aufrufe der Tools auch direkt ansehen.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

A. B. schrieb:

Hallo,

Ich musste beim avr-gcc 14.1.0 für Microchip Studio diesmal nicht wie 
sonst fehlende Dateien ergänzen. Es ist alles enthalten. Fremde/meine 
Toolchains verweisen immer auf das erste \bin Verzeichnis der Toolchain.

Hast du in Microchip Studio die Device Packs installiert?
Tools > Device Pack Manager

Verwendest du zum Toolchain bauen die aktuellen binutils 2.42?

: Bearbeitet durch User
von A. B. (Firma: ab) (bus_eng)


Angehängte Dateien:

Lesenswert?

Hallo Veit,

es ist alles aktuell und funktioniert auch.

mit  -B "$(PackRepoDir)\atmel\AVR-Dx_DFP\1.10.114\gcc\dev\avr128db48" 
werden die device-spezifischen Dateien ins Projekt eingefügt.

Das funktioniert bei Toolchain="NATIVE" auch out of the box.
Anders bei Toolchain="avr-gcc-14.1.0-x64-windows".
Da fehlt der entsprechende Eintrag im Makefile, obwohl
-B"$(PackRepoDir)\atmel\AVR-Dx_DFP\1.10.114\gcc\dev\avr128db48" unter 
|Toolchain|AVR/GNU Common|General| automatisch korrekt eingetragen wird.

Workaround siehe oben. Patch weiss ich nicht. Makefile wird immer neu 
generiert.

: Bearbeitet durch User
von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

wie hast du die Toolchain eingebunden?
Der schnellste Weg ist irgendein Projekt öffnen.
Projekt > Properties > Advanced > Flavour > Add Flavour
Name ausdenken und Pfad inkl. \bin angeben.
Danach steht es alle Projekten zur Verfügung.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

ich habe eine Vermutung. Die AVR-Dx Device Pack Version 1.10.114 wird es 
nicht mehr geben. Wenn das Zak Script das live runterladen möchte, 
könnte das übersprungen werden und fehlt am Ende. Aktuell ist 2.5.294.
http://packs.download.atmel.com/
Sieht man auch im Device Pack Manager.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe mich aufs Linux Eis bewegt.  :-)
Dabei befinde ich mich in einem Ordner worin die Toolchain direkt mit 
ihren 6 Unterordner ist und meine main.cpp liegt.
1
avr-gcc14TestSuite$ bin/avr-gcc main.cpp -c -o main.o -Os -std=c++20 -flto -mmcu=avr128db64 -I avr/include
2
avr-gcc14TestSuite$ bin/avr-gcc main.o -o main.elf -mmcu=avr128db64
3
avr-gcc14TestSuite$ bin/avr-objcopy -j .text -j .data -O ihex main.elf main.hex
4
avr-gcc14TestSuite$ bin/avr-size -d -A main.elf

Mit den Aufrufen sollte doch als Basis alles stimmen? Das Ergebnis von 
avr-size sieht stimmig aus. Warum baut man sich am Ende ein makefile und 
kein Bash File? Was ist das besondere am makefile was ein Bashfile nicht 
kann?

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Hallo,
>
> habe mich aufs Linux Eis bewegt.  :-)

Na prima, da ist alles einfacher. Schön, dass Du meiner Empfehlung 
gefolgt bist ;-)

> Dabei befinde ich mich in einem Ordner worin die Toolchain direkt mit
> ihren 6 Unterordner ist und meine main.cpp liegt.
>
1
> avr-gcc14TestSuite$ bin/avr-gcc main.cpp -c -o main.o -Os -std=c++20 
2
> -flto -mmcu=avr128db64 -I avr/include
3
> avr-gcc14TestSuite$ bin/avr-gcc main.o -o main.elf -mmcu=avr128db64
4
> avr-gcc14TestSuite$ bin/avr-objcopy -j .text -j .data -O ihex main.elf 
5
> main.hex
6
> avr-gcc14TestSuite$ bin/avr-size -d -A main.elf
7
>
>
> Mit den Aufrufen sollte doch als Basis alles stimmen?

Du brauchst für dieses einfache Programm aus nur einer Quelldatei keine 
zwei Schritte für Compilation und Linken. Geht in einem Aufruf des 
Frontends.

> Das Ergebnis von
> avr-size sieht stimmig aus.

Perfekt. Hast Du beide Varianten getestet?

> Warum baut man sich am Ende ein makefile und
> kein Bash File? Was ist das besondere am makefile was ein Bashfile nicht
> kann?

Wenn es größere Projekt sind, wir nur das gebaut, was tatsächlich sich 
geändert hat. Make ist ein regelbasiertes tool - es lohnt sich, sich 
damit bzw. anderen build-tools auseinander zu setzen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Georg P. schrieb:
> Selber kompilieren habe ich probiert, er findet aber 3 Libraries nicht.

Am einfachste geht das, indem man GCC die Libs mitgenerieren lässt.

Dazu führt man VOR configure ein
1
./contrib/download_prerequisites
im GCC Quellverzeichnis aus.

Das lädt die Quellen der benötigten Host-Libs (GMP, MPFR, MPC, ISL) ins 
GCC Quellverzeichnis.  Mit GCC configure und make werden die Libs dann 
automatisch mitgeneriert, unabhängig von im System installierten oder 
eben nicht-installierten Libs.

Der GCC Build dauert dann zwar etwas länger, aber dafür hat man allen 
GCC-Abhängigkeitsärger vom Hals.

> Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert.
> [...] Dem Compiler fehlte die passende glibc.

avr-gcc verwendet keine glibc sondern AVR-LibC als Target LibC.

Falls die entsprechende Version einer Host glibc fehlt, da kann ich 
leider nicht weiterhelfen.  Aber auf einem Linux-System ist avr-gcc ja 
flott generiert.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
1
> avr-gcc14TestSuite$ bin/avr-gcc main.o -o main.elf -mmcu=avr128db64
Mit -flto zu compilieren bring nix, wenn man nicht auch mit -flto linkt.
Außerdem hat man gerne -mrelax als Compile- und Linkoption, und linkt 
mit -Wl,--gc-sections (was dann compile mit -fdata-sections 
-ffunction-sections wünschenswert macht).
1
> avr-gcc14TestSuite$ bin/avr-objcopy -j .text -j .data -O ihex main.elf

Das Programm sollte mit avr-gcc v14 crashen, weil Output Section .rodata 
fehlt, siehe https://gcc.gnu.org/gcc-14/changes.html#avr

> Das Ergebnis von avr-size sieht stimmig aus.

Das stimmt aber nicht mir deinem HEX überein.

> Warum baut man sich am Ende ein makefile und kein Bash File?

Weil Make keine Skriptsprache ist, sondern es beschreibt Abhängigkeiten 
von Dateien, und wann und wie (Binär)Dateien neu generiert werden 
müssen.

Wenn man z.B. ein großes Projekt hat mit zig Quellen, dann würde ein 
Bash Script immer alles neu generieren auch wenn man nur eine einzige 
C/C++ Quelle geändert hat.

: Bearbeitet durch User
von A. B. (Firma: ab) (bus_eng)


Lesenswert?

Georg P. schrieb:
>> Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert.
>> [...] Dem Compiler fehlte die passende glibc.

Aktuelles zak script verwenden.
AFAIR fehlt den älteren das libmpfr-dev

script:
https://blog.zakkemble.net/avr-gcc-builds/

modifizierte avr-libc:
https://github.com/ZakKemble/avr-libc3

Quellen anpassen:

NAME_BINUTILS="binutils-${VER_BINUTILS:-2.42}"
NAME_GCC="gcc-${VER_GCC:-14.1.0}"
NAME_GDB="gdb-${VER_GDB:-14.2}"
NAME_GMP="gmp-6.3.0"
NAME_MPFR="mpfr-4.2.1"
NAME_LIBC="avr-libc3.git"
COMMIT_LIBC="d09c2a61764aced3274b6dde4399e11b0aee4a87"

von A. B. (Firma: ab) (bus_eng)


Lesenswert?

@Veit

In meinen Augen ist das ein Studio7-Bug beim generieren des Makefiles.

Die All-Options Felder von Compiler und Linker zeigen den -B "pfad", im 
Makefile fehlt er jedoch.

Wenn der -B "pfad" händisch im Compiler- und im Linker-Feld eingetragen 
wird, dann wird alles korrekt eingebunden.

@Georg P.

Nachtrag: Zielverzeichnis ändern. Weg von /root

. Output locations for built toolchains

. target dir - modify to keep results

BASE=${BASE:-/media/ab/Linux-HDD/avr-toolchain__/}

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

A. B. schrieb:
> Georg P. schrieb:
>>> Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert.
>>> [...] Dem Compiler fehlte die passende glibc.
> Aktuelles zak script verwenden.
> AFAIR fehlt den älteren das libmpfr-dev

Hat aber nix mit glibc zu tun?

> modifizierte avr-libc:
> https://github.com/ZakKemble/avr-libc3

Veraltet. Besser HEAD der originalen AVR-LibC verwenden.

> Quellen anpassen:
> NAME_GMP="gmp-6.3.0"
> NAME_MPFR="mpfr-4.2.1"

Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich 
mitgeneriert werden.

von Veit D. (devil-elec)


Lesenswert?

A. B. schrieb:
> @Veit
>
> In meinen Augen ist das ein Studio7-Bug beim generieren des Makefiles.

Ich denke nicht.

von A. B. (Firma: ab) (bus_eng)


Lesenswert?

Johann L. schrieb:

> Hat aber nix mit glibc zu tun?

Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit 
libmpfr-dev falsch läuft..

> Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich
> mitgeneriert werden.

Deine Bemerkungen helfen nur jenen. die dieses Toolchain-Geschäft schon 
beherrschen. Ich brauche einfach nur ein Script das ohne Fehler 
durchläuft. Das zak-skript tut genau das.

Ich schaue mir gerne ein funktionierendes Script von dir mit den oben 
beschriebenen Eigenschaften an, das dann auch die neuesten Libs enthält. 
Ich werde nie mit den Hinweisen von GNU und deinen Insider-Tips ein 
eigenes funktionierendes Script schreiben können.

Hier sind nicht alle Compilerentwickler oder Hochschulprofessoren. Die 
Mehrheit sucht ein brauchbares Werkzeug. AtmelStudio war ein Schritt in 
diese Richtung und mit aktuellem c++20 für mich immer noch interessant.

@Veit: ich denke schon.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

gut, Vorteil von make verstanden, spart erneute Kompilezeit. Mal sehen 
ob ich eine Blink Programm kompiliert bekomme was am Ende auch praktisch 
funktioniert.
Nur den Einwand mit "output section .rodata" verstehe ich nicht. Das 
muss ich selbst doch nicht angeben?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Nur den Einwand mit "output section .rodata" verstehe ich nicht. Das
> muss ich selbst doch nicht angeben?

Ausprobieren :-)

Bzw. warum gibst du .data an in
1
$ avr-objcopy -j .text -j .data -O ihex main.elf

wenn man es nicht angeben muss?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das hatte ich wo gelesen.  ;-)  Wenn ich alle Optionen selbst setzen 
muss erschlägt es mich. Ich hoffe das zu ändern.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

A. B. schrieb:
> Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit
> libmpfr-dev falsch läuft..

Gut, ist jetzt nicht so überrachend.  Wenn was falsch läuft, 
funktioniert es nicht.

Es ist nun mal eben nicht ganz so einfach ein Cross Build der Host-Libs 
zu machen; aber wenn du auf diesem holprigen Weg unterwegs sein magst, 
wird dich hier niemand aufhalten.

Wie's einfacher geht hab ich ja erklärt.

>> Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich
>> mitgeneriert werden.

> Deine Bemerkungen helfen nur jenen. die dieses Toolchain-Geschäft schon
> beherrschen.

Man muss eben vor configure ein bestimmtes Kommando ausführen. Mehr 
nicht.  Zu erklären, wie man bestimmte Kommantos ausführt würde jetzt 
uuch zu weit führen.

> Ich brauche einfach nur ein Script das ohne Fehler
> durchläuft. Das zak-skript tut genau das.

Dann ist ja alles gut.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> Wenn ich alle Optionen selbst setzen muss erschlägt es mich.

Wenn du avrdude verwendest: Der kann auch ELF Dateien flashen; es 
braucht also überhaupt kein HEX File.  Den alten Zopf kannst du also 
getrost abschneiden :-)

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

A. B. schrieb:
> @Veit: ich denke schon.

Meine Empfehlung. Bau in das Zak Script -x und -e ein und schau wann es 
abbricht/stoppt. Wenn du dir ein Bauscript selbst bauen möchtest wäre es 
besser dafür einen eigenen Thread zu eröffnen. Bin mir sicher das auch 
du dabei Hilfe bekommst. Als Basis verwende ich Ubuntu 22.04LTS in einer 
VM und bereite es vor mit
1
## UBUNTU VORBEREITEN ##
2
3
# fehlende Software zum Bauen nachinstallieren
4
> sudo apt-get update
5
> sudo apt-get upgrade
6
> sudo apt-get install aptitude
7
> sudo aptitude install build-essential autoconf automake libtool mingw-w64 subversion
8
# makeinfo installieren
9
> sudo aptitude install texinfo

@ Johann:
alles klar  :-)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

A. B. schrieb:
> Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit
> libmpfr-dev falsch läuft..

Hab mir Zak's Skript mal angeschaut. Für die GCC-Libs wird bereits 
download_prerequisites verwendet; da gibt's also keine Probleme mit GMP, 
MPFR etc.

MPFR wird jedoch für GDB gebraucht.  Wenn kein GDB benötigt wird, sollte 
also BUILD_GDB=0 das Problem vermeiden.  (Ob es einen zu GCC 
verglichbaren Mechanismus für die GDB Host-Libs gibt hab ich mir noch 
nicht angeschaut:)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Inzwischen wurde auch v13.3 released.

Der einzig nennenswerte Unterschied zu v13.2 (aus AVR-Sicht) ist, dass 
mehr Devices unterstützt werden, nämlich alle die auch v14.1 
unterstützt.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

diese schon wichtige Info fehlt leider im "Change" Text.

Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret? 
Abgesehen vom rodata Flash Feature. Was macht er im Untergrund anders 
bzw. besser?

von Wilhelm M. (wimalopaan)


Lesenswert?

Veit D. schrieb:
> Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret?

https://en.cppreference.com/w/cpp/compiler_support

Etwas nettes habe ich schon entdeckt ...

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

dort werden Sprachfeatures aufgelistet. Das meinte ich nicht. Das 
"rodata Flash" ist ja kein Sprachfeature. Das wurde speziell für den AVR 
eingebaut. Ich meinte die Frage so, was er intern vielleicht anders 
macht. Irgendwelche neuen Optimierungen. Ich meine wenn alles gleich 
bleiben würde, dann würde ich Laienhaft behaupten, dann dürfte die 
erzeugte Codegröße nicht atmen. Da sie atmet müssen ja intern immer 
irgendwelche Änderungen stattfinden. Vielleicht kann da jemand aus dem 
Nähkästchen plaudern.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

noch eine Frage zum avr-gcc 13.3. In "Change" wird AVR nicht erwähnt. 
Bedeutet das, dass die Patches PR105532 und PR109476 nicht im 13.3 
enthalten sind? Gibt es ggf. noch weitere Patches die man besser 
einbauen sollte?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Veit D. schrieb:
> diese schon wichtige Info fehlt leider im "Change" Text.

Rückportiert werden eigentlich nur relevante Bugfixes und Typos in der 
Dokumentation.  Neue Devices gehören nicht dazu; wurden aber 
rückportiert weil als unkritisch erachtet.

Solche Backports führen aber mitunter zu Überrachungen beim Anwender. 
Wenn zum Beispiel Device-Support vom aktuellen Entwicklungszweig zu 
v13.3 und v12.4 rückportiert wird, dann wird ein Anwender, der von v12.4 
auf v13.2 upgraded feststellen, dass bestimmte Devices "verschwunden" 
sind.  Das passiert weil immer mehrere GCC Major Versionen unterstützt 
werden, und v13.2 älter ist als zum Beispiel v12.4.

> Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret?

Allein in 2024 gab es bis zur v14 Release Anfang Mai über 50 Commits, 
das willste nicht alles in den Release-Notes sehen.  Relevante 
Änderungen sind .rodata-in-Flash für AVR64 und AVR128 Devices und ein 
neuer Optimierungs-Pass für Reduced Tiny.

Ob dieser Pass wirklich wichtig ist kann ich nicht beurteilen; viele 
Entwickler programmieren die Dinger vermutlich in Assembler.  Was aber 
evtl. auch daran liegt, dass der Code vom Compiler zu mies ist / war. 
Die Dinger in C/C++ zu programmieren ist bei 4k Flash wie beim ATtiny40 
ja auch nicht abwegeg.

Für Reduced Tiny wird dann der Support in der AVR-LibC auch etwas besser 
(pgm_read_xxx und string_P Funktionsn).

Veit D. schrieb:
> Das "rodata Flash" ist ja kein Sprachfeature. Das wurde speziell
> für den AVR eingebaut. [...] Irgendwelche neuen Optimierungen.

Wie gesagt bessere indirekte RAM-Zugriffe bei Reduced Tiny (PR114100)

Veit D. schrieb:
> eine Frage zum avr-gcc 13.3. In "Change" wird AVR nicht erwähnt.

Die Release Notes beziehen sich auf eine neue Major Release, also seit 
v5 die erste Zahl in der Versionsnummer.

> Bedeutet das, dass die Patches PR105532 und PR109476 nicht im 13.3
> enthalten sind?

Du meinst vermutlich PR105523.  Der wurde rückportiert.

PR109476 wurde nicht rückportiert weil es nur eine Optimierung ist.

> Gibt es ggf. noch weitere Patches die man besser einbauen sollte?

Da fällt mir nur PR101188 ein, der in v14 gefixt ist (und auch in der 
oben gelinkten v8.5.1), aber noch nicht auf v13 portiert wurde, 
vermutlich weil Jeff noch keine Zeit dafür hatte.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

die Infos muss man erstmal verdauen. Vielen Dank.

> Du meinst vermutlich PR105523
Ja, meinerseits ein Zahlendreher. Im Patch steht PR105523 drin, was 
damit übereinstimmt.

Ich fasse einmal zusammen.
PR105523 ... für avr-gcc 13.2.0 noch notwendig
"  --  " ... im avr-gcc 13.3.0 enthalten
PR101188 ... gibt es getrennt für avr-gcc 8 bzw. avr-gcc 13.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.