Nochmal Assemblerfehler AVR-GCC

Nov 24, 2006 10 Replies

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

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

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

"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.

"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.

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

"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.

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

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. ;-)

Nach mehrmaligem Durchgehen des Codeschnipsels...

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

-Andreas

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

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required