Forum: Compiler & IDEs section `.data' is not within region `data'


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 Andreas (ah3112)


Lesenswert?

Hallo,

ich habe eine Software für einen ATMega162 mit externem RAM. avr-size 
gibt mir folgende Meldung:
1
AVR Memory Usage
2
----------------
3
Device: atmega162
4
5
Program:    6270 bytes (38.3% Full)
6
(.text + .data + .bootloader)
7
8
Data:       3846 bytes (375.6% Full)
9
(.data + .bss + .noinit)

Wenn ich die Software mit dem "avr-gcc (WinAVR 20100110) 4.3.3" 
compiliere, läuft die einwandfrei. Es spielt auch keine Rolle, ob ich 
beim Linker "-Wl,-Tdata=0x800500,--defsym=__heap_end=0x807fff" angebe 
oder weglasse.

Sobald ich die aber mit der Version 7.3.0 compiliere, bekomme ich die 
Fehlermeldung "section `.data' is not within region `data'" bzw. 
"section `.bss' is not within region `data'".

Beim Linken habe ich folgende Parameter angegeben:
a)-Wl,--section-start,.data=0x800500,--defsym=__heap_end=0x807fff

b) -Wl,-Tdata=0x800500,--defsym=__heap_end=0x807fff

c) -Wl,-section-start=.data=0x800500

d) -Wl,-section-start=.data=0x800500 
-Wl,-section-start=XRAMSTART=0x800500

e) keinen der genannten Parameter

Es kommt jedesmal dieselbe Meldung des Linkers

Es werdem dazu noch die Adressen 0x800650 und
also:
address 0x800650 of Multitasking.elf section `.data' is not within 
region `data'
bzw.:
address 0x801440 of Multitasking.elf section `.bss' is not within region 
`data'

Meine Vermutung ist, dass es mit der Angabe des externen Rams zu tun 
hat. Ich weiss aber nicht, was ich dem Linker genau angeben muss bzw. wo 
der Fehler liegt.

Kann mir jemand einen Tipp geben?

Vielen Dank

von Bruno V. (bruno_v)


Lesenswert?

Andreas schrieb:
> Meine Vermutung ist, dass es mit der Angabe des externen Rams zu tun
> hat. Ich weiss aber nicht, was ich dem Linker genau angeben muss bzw. wo
> der Fehler liegt.
Du hast 3k8 RAM, der Prozessor scheinbar nur etwa 1k, deshalb zu >>100% 
voll

Andreas schrieb:
> Data:       3846 bytes (375.6% Full)

Kommt das in etwa hin? Also brauchst Du 3k8 RAM oder ist das ein Fehler, 
weil z.B. 3k Teststrings irrtümlich im RAM statt nur ROM gelandet sind?

von Andreas (ah3112)


Lesenswert?

Bruno V. schrieb:
> Du hast 3k8 RAM, der Prozessor scheinbar nur etwa 1k, deshalb zu >>100%
> voll
Danke erstmal für Deine schnelle Antwort.

Das stimmt. Aber ich habe 32k externen Ram. Sorry, ist aus meinem 
Beitrag nicht klar geworden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Aber ich habe 32k externen Ram.

Das musst du dem Linker auch mitteilen.

Früher™ nahm der Linker per default sehr viel RAM an, egal wieviel der 
konkrete AVR wirklich hatte. Jetzt ist das genauer herunter gebrochen 
worden, mit der exakten Menge an RAM für jeden AVR.

Probier mal, ob
1
-Wl,--defsym=__DATA_REGION_LENGTH__=32768

funktioniert. Das wäre zumindest das Symbol, auf das der Linkerscript 
zurück greift. Kann auch sein, dass man das über den Compiler mitteilen 
kann – vielleicht schlägt Johann ja hier auf und weiß aus dem Hut mehr 
dazu.

von Andreas (ah3112)


Lesenswert?

Jörg W. schrieb:
> Probier mal, ob
> -Wl,--defsym=__DATA_REGION_LENGTH__=32768
>
> funktioniert. Das wäre zumindest das Symbol, auf das der Linkerscript
> zurück greift. Kann auch sein, dass man das über den Compiler mitteilen
> kann – vielleicht schlägt Johann ja hier auf und weiß aus dem Hut mehr
> dazu.
Perfekt. Du bist der Beste. Es ist nicht nur so, dass die Software sich 
fehlerfrei compilieren und linken lässt, sie läuft auch.

Vielen Dank

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Siehe zum Beispiel die AVR-LibC Doku zu "Symbols in the Default Linker 
Script":

https://avrdudes.github.io/avr-libc/avr-libc-user-manual/mem_sections.html#sec_symbols

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich dachte mir, dass Johann noch eine bessere Antwort weiß: er kennt 
sogar die Dokumentation. ;-) Ich hatte nur kurz in den Linkerscript 
geschaut.

von Andreas (ah3112)


Lesenswert?

Johann L. schrieb:
> Siehe zum Beispiel die AVR-LibC Doku zu "Symbols in the Default Linker
> Script":
Erstmal auch Dir danke für Deine Bemühungen.

Aber irgendwie funktioniert das nicht oder ich habe es nicht verstanden. 
Es gibt immer noch Fehler beim Linken. Folgendes habe ich ausprobiert 
und beim Linken übergeben:
1
-Wl,--defsym=__data_start=0x0500 -Wl,--defsym=__data_end=0x7FFF

oder
1
-Wl,--defsym=__data_load_start=0x0500 -Wl,--defsym=__data_load_end=0x7FFF

oder
1
-Wl,--defsym=__heap_start=0x0500

Bei allen drei Versuchen bekomme ich immer angezeigt:
section `.bss' is not within region 'data' und als Adresse 0x801040

Kannst Du mir sagen, wie der Aufruf richtig sein muss?

Vielen Dank

von Andreas (ah3112)


Lesenswert?

Ich habe es gerade auch nochmal folgendermassen getestet:
1
-Wl,--defsym=__data_start=0x800500 -Wl,--defsym=__data_end=0x807FFF
und
1
-Wl,--defsym=__data_load_start=0x800500 -Wl,--defsym=__data_load_end=0x807FFF
und
1
-Wl,--defsym=__heap_start=0x800500


Weil ich dachte, ich hätte mich von AVR-Studio irritieren lassen. Dort 
muss das ohne 0x80 angegeben werden.

Aber das Ergebnis bleibt dasselbe. Irgendwas mache ich falsch. Es 
funktioniert bisher nur mit der von Jörg vorgeschlagenen Lösung

von Bauform B. (bauformb)


Lesenswert?

Nur zwecks der Neugier: Früher hätte man sowas per Linker Script 
geregelt, einfach und übersichtlich. Ist das hier AVR-spezifisch oder so 
eine neumodische IDE-Erfindung?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Diese Symbole werden im Linker Script gesetzt und können im Programm 
verwendet werden.  Zum Beispiel braucht der Startup Code diese Symbole, 
um Static Storage korrekt initialisieren zu können.  Diese Symbole 
umzudefinieren ist so, als würdest du schreiben
1
#define INT_MAX 2147483647
und dann erwarten, dass int ein 32-Bit Typ ist.

Wie es geht, hat Jörg bereits geschrieben:

Das Layout der data Region kann durch Definieren der genannten Symbole 
angepasst werden
1
-Tdata=START -Wl,--defsym,__DATA_REGION_ORIGIN__=START -Wl,--defsym,__DATA_REGION_LENGTH__=LEN
wobei START die Startadresse der Region ist und LEN deren Länge in 
Bytes, also zum Beispiel LEN=32k.

__DATA_REGION_ORIGIN__wurde erst mit Binutils v2.40  2023-01-14  
PR29741 eingeführt; mit älteren Versionen endet die data Region also vor 
dem physikalischen Ende vom XRAM.  Eine mögliche Abhilfe ist, LEN so zu 
vergrößern, dass data bis zum Ende vom XRAM reicht.

Dann bleibt noch die Frage, wo der Stapel liegen soll.  Üblicherweise 
nutzt der das interne SRAM, und daher wird SP mit RAMEND weak 
initialisiert.   Falls SP einen anderen Startwert erhalten soll, dann 
kann man Symbol __stack entsprechend setzen.

Bauform B. schrieb:
> Nur zwecks der Neugier: Früher hätte man sowas per Linker Script
> geregelt, einfach und übersichtlich. Ist das hier AVR-spezifisch oder so
> eine neumodische IDE-Erfindung?

Ein Symbol zu definieren ist immer noch einfacher, als ein eigenes 
Linker Script zu maintainen.  Die o.g. Symbole werden ja vom default ld 
Script verwendet, also gibt es keinen Grund, das Rad neu zu erfinden.

: Bearbeitet durch User
von Andreas (ah3112)


Lesenswert?

Johann L. schrieb:
> Das Layout der data Region kann durch Definieren der genannten Symbole
> angepasst werden-Tdata=START -Wl,--defsym,__DATA_REGION_ORIGIN__=START
> -Wl,--defsym,__DATA_REGION_LENGTH__=LEN
> wobei START die Startadresse der Region ist und LEN deren Länge in
> Bytes, also zum Beispiel LEN=32k.
Danke Dir. Werde ich nächste Woche ausprobieren. Dieses Wochenende 
schaffe ich es nicht mehr.

Johann L. schrieb:
> Ein Symbol zu definieren ist immer noch einfacher, als ein eigenes
> Linker Script zu maintainen.
Das war auch mein Horror. Ich hatte nur nach der Fehlermeldung gegoogelt 
und dort wurde mehrfach erwähnt, das Linkerscript anzupassen. Damit wäre 
ich aber wahrscheinlich hoffnungslos überfordert gewesen.

Vielen Dank Euch beiden für die gute Hilfe

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Damit wäre ich aber wahrscheinlich hoffnungslos überfordert gewesen.

Ist keine Raketenwissenschaft. Insgesamt aber finde ich den Ansatz der 
AVR-GNU-Toolchain, generische Linkerscripts mitzuliefern und damit alles 
"aus der Dose 'raus" aus einer Hand zu haben viel besser als das 
Gewurschtel bei ARM (jetzt mal auf Cortex-M bezogen), wo jede IDE jedes 
Herstellers ihr eigenes Linkerscript und natürlich dazu passend ihren 
eigenen Startup-Code mitliefert.

von Vanye R. (vanye_rijan)


Lesenswert?

> Ein Symbol zu definieren ist immer noch einfacher, als ein eigenes
> Linker Script zu maintainen.

Ich weiss nicht. Was gibt es da gross zu maintainen? Ich hab
fuer alle meine Projekte immer ein eigenes Linkerscript.
Beim aufsetzen kopiere ich das schamlos von einem alten
Projekt, lese das einmal mit eingeschaltetem Verstand durch
und passe 1-2 Werte an und nur wenn sich was ernstes
an meinem Projekt aendert gehe ich da nochmal rein.

Vanye

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> Ich hab
> fuer alle meine Projekte immer ein eigenes Linkerscript.

Kann man machen, muss man aber nicht.

Code für einen AVR kannst du halt¹ mit sowas wie
1
avr-gcc -Os -mmcu=atmega328p -o myfile.elf myfile.c

compilieren, und das bestehende ELF-File kannst du wie es ist flashen. 
Bequemer geht's nicht, finde ich. Der einzige nennenswerte Unterschied 
zum Compilieren eines Host-Programms ist die Angabe des MCU-Typs.

¹ Natürlich nur, wenn das Setup keine Besonderheiten hat wie eben hier 
der externe RAM.

: Bearbeitet durch Moderator
von Andreas (ah3112)


Lesenswert?

Jörg W. schrieb:
> Probier mal, ob
> -Wl,--defsym=__DATA_REGION_LENGTH__=32768
>
> funktioniert.

Johann L. schrieb:
> Das Layout der data Region kann durch Definieren der genannten Symbole
> angepasst werden-Tdata=START -Wl,--defsym,__DATA_REGION_ORIGIN__=START
> -Wl,--defsym,__DATA_REGION_LENGTH__=LEN
> wobei START die Startadresse der Region ist und LEN deren Länge in
> Bytes, also zum Beispiel LEN=32k.

Ich wollte mich bei Euch beiden nochmal bedanken. Ich habe es heute 
morgen getestet. Die Software funktioniert mit Euren Angaben perfekt.

Allerdings habe ich noch was (zumindest für mich) erstaunliches 
festgestellt.

Wenn ich die Software mit der Version 4.3.3 compiliere und linke, dann 
funktioniert die auch, wenn ich beim linken nicht angebe, dass der 
externe RAM vorhanden ist. An Ram wird über avr-size angegeben, dass 
322,3% benötigt werden. Sobald ich aber den RAM nur geringfügig erhöhe 
(329,7%) läuft meine Software nicht mehr. Selbst wenn ich beim Linken 
angebe, dass der externe RAM vorhanden ist.

Wird exakt dieselbe Software mit dem avr-gcc 7.3.0 erstellt, läuft die 
Software einwandfrei. Beim Linken muss aber:
1
-Wl,-Tdata=0x800500 -Wl,--defsym,__DATA_REGION_ORIGIN__=0x800500 -Wl,--defsym=__DATA_REGION_LENGTH__=32768
angegeben werden.

Dieselbe Software für den AT90CAN128 funktioniert aber auch mit der 
Version 4.3.3. Hier ist jedoch kein externer Ram angeschlossen und auch 
nicht beim Linken eingestellt, weil der genug internen hat.

Es wird also Zeit, dass ich mal auf eine neue Version umsteige. Bisher 
habe ich das immer vermieden, da es mit dem Eclipse-Plugin so schön 
einfach war. Aber das funktioniert seit einiger Zeit, aufgrund von 
Änderungen bei avr-dude, sowieso nicht mehr vollständig.

Aber trotzdem vielen Dank. Ihr habt mir richtig weitergeholfen. Ohne 
Euch wäre ich aufgeschmissen gewesen.

von Oliver S. (oliverso)


Lesenswert?

Andreas schrieb:
> Aber das funktioniert seit einiger Zeit, aufgrund von Änderungen bei
> avr-dude, sowieso nicht mehr vollständig.

Hm. Seit wann denn genau?

Oliver

von Andreas (ah3112)


Lesenswert?

Oliver S. schrieb:
> Hm. Seit wann denn genau?
Habe ich vor ein paar Wochen festgestellt, als ich auf eine neue Version 
von avr-dude umsteigen musste. Normalerweise könnte man das über das 
Eclipse-Plugin ganz komfortabel einstellen und die Software auch 
übertragen. Das geht jetzt nicht mehr. Hab irgendwo gelesen, dass in den 
config-Dateien von avrdude was geändert wurde und deshalb das 
eclipse-plugin nicht mehr funktioniert. Dafür habe ich mir eine 
Batch-Datei erstellt. Ist nur nervig, wenn man den Controller wechselt.

Der Programmierer des Plugins, Thomas Holland, war damals auch hier im 
Forum aktiv. Aber ich glaube das letzte Update ist schon was länger her.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Andreas schrieb:
> Wenn ich die Software mit der Version 4.3.3 compiliere und linke, dann
> funktioniert die auch, wenn ich beim linken nicht angebe, dass der
> externe RAM vorhanden ist.

Kommt auf die Distro an. Bei v4.3.3 vermutlich WinAVR-20100110 o.ä.

Wie gesagt ist die Compilerversion unerheblich, was zählt ist die 
Binutils-Version und welche Patches da reingepackt sind.  Ein Binutils 
Install enthält Kopien die default ld-Skripte in 
$prefix/avr/lib/ldscripts

Interessant ist hier die Definition der data Region: Zunächst war es
1
data   (rw!x) : ORIGIN = $DATA_ORIGIN, LENGTH = $DATA_LENGTH
dann 2015
1
data   (rw!x) : ORIGIN = $DATA_ORIGIN, LENGTH = __DATA_REGION_LENGTH__
und 2023 schließlich
1
data   (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__

Geschichte: 
https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=ld/scripttempl/avr.sc;hb=HEAD

Dabei sind die $-Werte architekturspezische (genau genommen 
Emulation-spezifische) Konstanten, die idR so definiert sind, dass

$DATA_ORIGIN + $DATA_LENGTH = 64 KiB.

Die __-Werte sind Symbole, deren default-Wert der jeweilige $-Wert ist. 
Wenn also niemand (zB Startup-Code oder Anwender) die Symbole definiert, 
dann ändert sich auch nix an deren Wert.

Definition der $-Werte geschieht in den avr*.sh Dateien: 
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=ld/emulparams;hb=HEAD

Exakte Werte sind nützlich, damit der Likner meckert wenn eine Region 
überläuft und damit nicht in die Hardware passt.  Ist die Region zu 
groß, damm stört das den Linker nicht; es kann aber sein, dass ein nicht 
funktionierender Code erstellt wird.  Und das ist natürlich mühsam zu 
debuggen.

> An Ram wird über avr-size angegeben, dass 322,3% benötigt werden.

Also eine hornalte Version von avr-size mit Patches, die es nie ins 
offizielle Repo geschafft hat.

> Sobald ich aber den RAM nur geringfügig erhöhe
> (329,7%) läuft meine Software nicht mehr. Selbst wenn ich beim Linken
> angebe, dass der externe RAM vorhanden ist.

Was heißt "RAM erhöhen" ?

Wie gesagt: Aufs Linken an sich hat da keinen Einfluss, lediglich auf 
Diagnostics.

> -Wl,--defsym=__DATA_REGION_LENGTH__=32768

Geht übrigens auch kürzer als ...=32k

von Andreas (ah3112)


Lesenswert?

Erstmal Danke, dass Du Dir noch die Mühe gemacht hast, das nochmal so 
detailliert zu erklären.

Johann L. schrieb:
> Bei v4.3.3 vermutlich WinAVR-20100110 o.ä.
Stimmt, genau die. Die hatte ich damals installiert, ich glaube als ich 
angefangen habe eclipse zu verwenden. Da die bisher immer funktioniert 
hatte, habe bin ich meinen Grundsätzen (Never touch a running system) 
treu geblieben. Aber jetzt geht es wohl nicht mehr.

Johann L. schrieb:
> Interessant ist hier die Definition der data Region: Zunächst war es
Ich habe versucht mit der alten Version (WinAVR-20100110) und den Linker 
mit folgendem Parameter aufgerufen:
1
-Wl,--defsym=ORIGIN=0x800500  -Wl,--defsym=LENGTH=32k
Es funktioniert aber nicht. Möglicherweise habe ich das aber auch nicht 
richtig verstanden und die Definitionen sind falsch. Die Software läuft 
dann nicht mehr an, wenn ich den "RAM erhöhe" (Erklärungen dazu später).

Johann L. schrieb:
> Also eine hornalte Version von avr-size mit Patches, die es nie ins
> offizielle Repo geschafft hat.
Das verstehe ich nicht. Selbst wenn ich avr-size aus der avr-version 
7.3.0 nehme, habe ich diese Angabe.

Johann L. schrieb:
> Was heißt "RAM erhöhen" ?
RAM erhöhen war von mir bescheuert ausgedrückt. Es hätte wohl besser 
"Ram-Verbrauch erhöhen" heissen müssen. Kurz zur Erklärung, wie ich das 
meinte. Ich habe ein Array, darin sind die einzelnen Elemente 
Strukturen. Diese Strukturen bestehen aus einer Vielzahl von Elementen 
mit unsigned int und unsigned char. Wenn ich das Array um 2 Einträge 
erhöhe, dann läuft die Software nicht mehr. Das ist allerdings nur bei 
WinAVR2010 so, bzw. wie Du geschrieben hattest, bei der dazugehörigen 
Version von Binutils. Erstelle ich das Ganze mit avr 7.3.0 und nehme 
auch die entsprechend Binutils-Version, dann klappt es.

Johann L. schrieb:
> Geht übrigens auch kürzer als ...=32k
Danke, ist geändert.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Selbst wenn ich avr-size aus der avr-version 7.3.0 nehme, habe ich diese
> Angabe.

"avr-version 7.3.0", was genau ist das?

Vermutlich Microchips mit privaten Patches zusammen gefrickelte 
Toolchain.

In den regulären Tools gibt jeweils separate Versionen für GCC, Binutils 
und AVR-LibC, da diese auch separat gepflegt werden.

In den regulären Binutils hat das size-Kommando ebendiese AVR-Patches 
nie gesehen, und deren ursprünglicher Autor (dürte noch von Eric 
Weddington stammen) hatte damals auch gleich gesagt, dass er gar nicht 
die Absicht hatte, das als offizielle Patches einzureichen – eben weil 
ihm klar war, dass so ein Hack da nie offiziell Bestand haben würde.

von Andreas (ah3112)


Lesenswert?

Jörg W. schrieb:
> "avr-version 7.3.0", was genau ist das?
>
> Vermutlich Microchips mit privaten Patches zusammen gefrickelte
> Toolchain.
Ich musste erst noch einmal suchen woher ich die hatte. Deine Vermutung 
stimmt. 
https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SoftwareTools/avr8-gnu-toolchain-3.7.0.1796-win32.any.x86_64.zip

Jörg W. schrieb:
> In den regulären Tools gibt jeweils separate Versionen für GCC, Binutils
> und AVR-LibC, da diese auch separat gepflegt werden.
Wo finde ich die? Ich bin davon ausgegangen, dass das, wenn die von 
Microchip sind, was vernünftiges ist.

Jörg W. schrieb:
> In den regulären Binutils hat das size-Kommando ebendiese AVR-Patches
> nie gesehen, und deren ursprünglicher Autor (dürte noch von Eric
> Weddington stammen) hatte damals auch gleich gesagt, dass er gar nicht
> die Absicht hatte, das als offizielle Patches einzureichen – eben weil
> ihm klar war, dass so ein Hack da nie offiziell Bestand haben würde.
Das habe ich nicht verstanden. Ich das avr-size nicht schlecht, wenn es 
mir den benötigten Flash und Ram anzeigt. Warum war ihm klar, dass das 
nichts offizielles wird?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Jörg W. schrieb:
>> In den regulären Tools gibt jeweils separate Versionen für GCC, Binutils
>> und AVR-LibC, da diese auch separat gepflegt werden.
>
> Wo finde ich die?

Beispielsweise in den Ausgaben der einzelnen Tools:
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.
6
7
$ avr-ld --version
8
GNU ld (GNU Binutils) 2.40
9
Copyright (C) 2023 Free Software Foundation, Inc.
10
This program is free software; you may redistribute it under the terms of
11
the GNU General Public License version 3 or (at your option) a later version.
12
This program has absolutely no warranty.

Schwieriger ist es für die AVR-LibC, da es für diese keine installierten 
ausführbaren Kommandos gibt. Hier musst du entweder deine 
Paketquellenverwaltung fragen, oder wenn du weißt, wo die Dateien 
installiert sind, kannst du dir den Inhalt von version.h anzeigen 
lassen:
1
$ cat /usr/local/avr/include/avr/version.h 
2
/* Copyright (c) 2005, Joerg Wunsch                               -*- c -*-
3
   All rights reserved.
4

5
6
/** \ingroup avr_version
7
    String literal representation of the current library version. */
8
#define __AVR_LIBC_VERSION_STRING__ "2.3.0git"

(In meinem Falle ist es also eine Entwicklerversion direkt aus dem Git, 
die ich installiert habe.)

> Das habe ich nicht verstanden. Ich das avr-size nicht schlecht, wenn es
> mir den benötigten Flash und Ram anzeigt. Warum war ihm klar, dass das
> nichts offizielles wird?

Weil die GNU Binutils generisch für eine riesige Palette von CPUs (und 
MCUs) sind, der Hack aber lediglich AVRs beinhaltete, und davon dann 
halt auch noch eine eigene Kopie dieser Information.

Wenn man es hätte richtig machen wollen, hätte man eine Kopie dieser 
Information irgendwo im Dateisystem hinterlegt und dann sowohl GCC, ggf. 
den Linker und eben das size-Kommando darauf zugreifen lassen, und hätte 
dies für alle möglichen MCUs zumindest bereitstellen sollen. Die gesamte 
Klasse der Cortex-M MCUs hat ja nicht weniger Bedarf an derartiger 
Information.

Da Eric dazu keine Motivation hatte, blieb es halt ein Hack, den er in 
sein WinAVR eingebaut hat, ohne dass der jemals offizialisiert worden 
wäre.

: Bearbeitet durch Moderator
von Andreas (ah3112)


Lesenswert?

Jörg W. schrieb:
> Beispielsweise in den Ausgaben der einzelnen Tools:
Das hatte ich falsch ausgedrückt. Mit
"Wo finde ich die?"
meinte ich, wo ich die regulären Tools zum Download finde. Bei Dir steht 
dort z.B. "avr-gcc (GCC) 14.1.0". Bei mir 4.3.3.
Im Rahmen meiner Fehlersuche habe ich versucht die aktuellen, 
offiziellen Versionen der Tools und allem drumherum zu finden. Dabei 
habe ich nur die von mir genannten gefunden.

Jörg W. schrieb:
> Da Eric dazu keine Motivation hatte, blieb es halt ein Hack, den er in
> sein WinAVR eingebaut hat, ohne dass der jemals offizialisiert worden
> wäre.
Danke für die Erklärung. Habe ich jetzt verstanden.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Schwieriger ist es für die AVR-LibC, da es für diese keine installierten
> ausführbaren Kommandos gibt.

In einer Shell kann man zum Beispiel:
1
$ echo "#include <avr/version.h>" | avr-gcc -xc - -E -dM | grep LIBC
2
#define __AVR_LIBC_VERSION__ 20200UL
3
#define __AVR_LIBC_DATE_ 20220701UL
4
#define __AVR_LIBC_MAJOR__ 2
5
#define __AVR_LIBC_VERSION_STRING__ "2.2.0git"
6
#define __AVR_LIBC_MINOR__ 2
7
#define __AVR_LIBC_DATE_STRING__ "20220701"
8
#define __WITH_AVRLIBC__ 1
9
#define __AVR_LIBC_REVISION__ 0

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Mit
> "Wo finde ich die?"
> meinte ich, wo ich die regulären Tools zum Download finde.

Beim Packager deines geringsten Misstrauens.

Tools wie GCC oder GNU Binutils oder AVR-LibC liefern erst einmal nur 
Sourcecode.

Den kannst du jetzt selbst compilieren, oder du suchst dir jemanden, der 
ihn für dich compiliert.

Ich kann dir leider nicht sagen, wer sowas aktuell für Windows macht. 
Bei den typischen Linux-Distributionen oder auch bei FreeBSD (wo ich 
eher zu Hause bin) hast du mehr oder minder aktuelle Versionen in deren 
jeweiligen Vertriebskanälen dabei, die das für dich vorcompilieren.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Andreas schrieb:
1
-Wl,--defsym=__data_start=0x800500

Johann L. schrieb:
> Diese Symbole werden im Linker Script gesetzt und können im Programm
> verwendet werden.  Zum Beispiel braucht der Startup Code diese Symbole,
> um Static Storage korrekt initialisieren zu können.  Diese Symbole
> umzudefinieren ist so, als würdest du schreiben
>
1
#define INT_MAX 2147483647
> und dann erwarten, dass int ein 32-Bit Typ ist.

Hab die Doku mal angepasst. Wenn jemand so einen Fehler macht, dann ist 
das keine Fehler des Anwenders, sondern der Doku...

von Andreas (ah3112)


Lesenswert?

Johann L. schrieb:
> Hab die Doku mal angepasst. Wenn jemand so einen Fehler macht, dann ist
> das keine Fehler des Anwenders, sondern der Doku...
Meinst Du mich damit? Ich verstehe nicht, wo ich das in der Doku 
anpassen soll. Hatte auch erst jetzt wieder Zeit reinzusehen, sonst 
hätte ich mich eher gemeldet.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas schrieb:
> Ich verstehe nicht, wo ich das in der Doku anpassen soll.

Die Aussage war: "Hab das in der Doku angepasst." Da ist ein "ich" am 
Anfang des Satzes weggelassen worden. ;-)

von Andreas (ah3112)


Lesenswert?

Jörg W. schrieb:
> Die Aussage war: "Hab das in der Doku angepasst." Da ist ein "ich" am
> Anfang des Satzes weggelassen worden. ;-)
Ah, ok. Danke

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.