1. Home
  2. Electronics (German)
  3. Nochmal Assemblerfehler AVR-GCC

Nochmal Assemblerfehler AVR-GCC

Hallo zusammen!

Ich hatte ja kürzlich schonmal wegen eines merkwürdigen Fehlers beim Arbeiten mit dem AVR-GCC gemeldet. Inzwischen habe ich mal ein Assembler-File erzeugt. Hier das Ergebnis:

"make.exe" all avr-gcc -g -O1 -Wall -Wstrict-prototypes -Wa,-ahlms=main.lst

-mmcu=atmega128 -c -o main.o main.c C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s: Assembler messages: C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:57111: Error: value of

66144 too large for field of 2 bytes at 16 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64866: Error: value of 65692 too large for field of 2 bytes at 9941 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64884: Error: value of 65692 too large for field of 2 bytes at 9961 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64886: Error: value of 65718 too large for field of 2 bytes at 9963 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64907: Error: value of 65718 too large for field of 2 bytes at 9988 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64909: Error: value of 65720 too large for field of 2 bytes at 9990 C:\DOKUME~1\ost_dri\LOCALS~1\Temp/ccq4aaaa.s:64966: Error: value of 65720 too large for field of 2 bytes at 10065

Assembler-File ab Zeile 64881:

.byte 0x6 .byte 0xdb .byte 0x1 .word .LFB136

.word .LFE136

.byte 0x8 .byte 0x90 .uleb128 0x20 .byte 0x93 .uleb128 0x1 .byte 0x90 .uleb128 0x21 .byte 0x93 .uleb128 0x1

Das sieht für mich nach der Definition von Konstanten aus. Das eigentliche Programm scheint schon bei Zeite 35.xxx zu Ende zu sein?

Ich verstehe nur nicht, wie die Werte in den Konstanten zu groß werden können, wenn die Menüstruktur im Hauptprogramm länger wird?!

Gruß Thorsten .uleb128 0x16 .long 10047

.byte 0x1 .long .LASF147

.byte 0x6 .word 274

.byte 0x1 .word .LFB137

.word .LFE137

Reply to
Thorsten Ostermann
Loading thread data ...

Wenn man mal grob davon ausgeht, dass eine Zeile Assembler so um ein Wort Code erzeugt, ist es kein Wunder. Die Referenzierung der Konstantenadresse passt einfach nicht mehr in 16Bit...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias
Reply to
Georg Acher

Schuss ins Blaue: kann es sein, dass das die Debug-Informationen sind, die schlicht zu groß werden? So wüste ".byte" ".word" ".uleb128" Orgien kenne ich zumindest vom i386 nur aus den DWARF-Debug-Informationen. Dann müsste sich über dem Beginn der Tabelle eine Anweisung wie ".section .debug_frame" finden.

Workaround wäre dann wohl, für dieses Modul -g wegzulassen.

Stefan

Reply to
Stefan Reuther

"Thorsten Ostermann":

Was bedeutet diese Fehlermeldung denn eigentlich? Speziel die Zahlen 64866 und 9941? Vor letzterer steht ja ein "at", was für mich so klingt, als wär's eine Zeilennummer.

Reply to
Jan Bruns

"Jan Bruns" schrieb im Newsbeitrag news:4568744b$0$5726$ snipped-for-privacy@newsspool3.arcor-online.net...

65692 = 10000000010011100 binaer sind halt mehr als 16 bit, 64866 ist die Zeilenummer im temporaeren Assemblerquelltext ccq4aaaa.s und 9941 vermutlich die Zeilennummer in Originalprogramm main.c 
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Reply to
MaWin

Hallo MaWin!

Nur das die einzelnen Dateien keine 9.000 Zeilen haben. Jetzt müßte man wissen, in welcher Reihnefolge der Compiler die Sourcen zusammenstellt.

Es sieht aber so aus, als wären aus meinem Codeschnipsel oben die beiden .word .LFB136 das Problem? Wofür steht das L? Gehört das F noch zur Zahl/Adresse?

Gruß Thorsten

Reply to
Thorsten Ostermann

"Thorsten Ostermann" schrieb im Newsbeitrag news: snipped-for-privacy@mid.dfncis.de...

Es sieht so aus, als ob deine Compileroptionen oder gar der zu schlecht optimierende Compiler das Problen darstellt, denn das Programm wird bei jemand anderem wohl mal in 64k gepasst haben.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Reply to
MaWin

Hallo MaWin!

Wie kommst du darauf? Die unveränderten Sourcen kann ich problemlos kompilieren. Erst wenn ich Erweiterungen einfüge komme ich irgendwo an den Punkt, an dem es nicht mehr läuft. Das Binary ist übrigens größer als 64 kB, was aber kein Problem sein sollte, weil die 128kB im Mega128 ja als 2*64kB organisiert sind und somit wortweise addressiert werden.

Gruß Thorsten

Reply to
Thorsten Ostermann

Thorsten Ostermann schrieb:

Das .L steht für `local label' (diese werden nicht in die Symboltabelle übernommen, die der Linker sieht). Alles zusammen (als mit dem Punkt und dem L) ist das aber weiter nichts als ein Name. Der Label muss folglich in der Assemblerdatei noch einmal auftauchen.

Ich habe die Befürchtung, dass deine Codekomplexität hier einfach zu groß wird, beispielsweise versucht wird, eine switch/case-Anweisung über mehr als 64 KiB an Code zu erzeugen. Wobei ich mir nicht ganz sicher bin hier: die Code-Adressierung im AVR schiebt ja ein Bit nach rechts, könnte sein, dass eine Sprungtabelle in switch/case das bereits in der Tabelle berücksichtigt (also nicht erst zur Laufzeit schiebt).

Die Sprungtabellen für switch/case kann man mit -fno-tablejump abschalten. Da wird dann das Äquivalent zu vielen if/else if/else Anweisungen gebaut. Ist bei vielen case labels wohl eher uneffektiv.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Nach mehrmaligem Durchgehen des Codeschnipsels...

Es geht doch um .LFB136 und .LFE136. Könnte B und E für Begin und End stehen?

-Andreas

Reply to
Andreas Eibach

Das sind ganz normale Labels. Irgendwo im Code gibt es ".LFB136:" und ".LFE136:". Vermutlich stehen die für irgendwelche Anfägen und Enden, aber das ist eine Konvention des Compilers, keine des Assemblers oder Linkers. Und vermutlich beschreibt der Compiler dort eben dem Debugger gerade die Lebenszeit einer Variablen oder sowas.

Stefan

Reply to
Stefan Reuther

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.