Atmel Studio 4 (.19) stürzt bei ungünstigem Code ab

J.G. S. schrieb:
> Jedoch bei compileroption -gstrict-dwarf  funktioniert es wieder.

Deren selbstgefeilter DWARF-Parser war einfach grottig.  Der war nicht
nach dem DWARF-Standard geschrieben worden, sondern offenbar mit
trial&error auf den damals üblichen GCC manuell angepasst.  In der
Folge darfst du ihm halt nun keinen neueren Compiler unterschieben,
der irgendwelche anderen DWARF-Elemente generiert.  Ein ordentlicher
Parser könnte die zwar ignorieren (auch, wenn er sie dazumals noch
gar nicht kennen konnte), aber dann hätte man sich eben an den
Standard halten müssen …

Dafür habe ich mir diesen Link bei den Favoriten abgelegt, falls ich mal 
was neu installieren muss:
Beitrag "Avr Studio 4 und die neue AVR Toolchain - So funktionierts!"

Ahhja, habe schon vermutet dass das für euch ein alter Hut ist.
Und sowas interessiert keine Sau? Also mir wäre das peinlich.
Es fällt ja doch etwas auf, wenn die IDE da plötzlich das Licht 
ausmacht.

Muss ich mich da sonst noch auf Überraschungen gefasst machen, also wenn 
ich -gstrict-dwarf nicht vergesse? Am liebsten suche ich nämlich meine 
eigenen Fehler :-)

Bis jetzt hab ich die kleinen AVRs fast nur mir 4.18-3 geschrieben. Geht 
ja ganz brauchbar. Aber leider macht der ums verrecken keine langen 
CALLs wenn man ihm etwas grösseren C/ASM Mix unterschiebt. Und ständig 
die Compilier-Reihenfolge umzutauschen, das klappt auch irgendwann nicht 
mehr. Ja, da dachte ich mir, biste ganz verrückt und gönnst dir mal was 
Neues, hmm...  :-)

J.G. S. schrieb:
> Und sowas interessiert keine Sau?

Nicht mehr, schließlich ist das AVR Studio 4 schon seit mehreren
Jahren aus der Wartung raus.

J.G. S. schrieb:
> AVR Studio 4.19 (730)

ist das nicht auch ein Grund beim 4.18 SP3 zu bleiben oder gibt es den 
Fehler da auch?

Joachim B. schrieb:
> oder gibt es den Fehler da auch?

Gegenfrage: warum sollte es den dort nicht geben?  Benutzt doch
schließlich einen gleichermaßen handgestrickten DWARF-Parser.

Erst mit der 5er Linie (die dann zwecks Hinzuziehung der ARMs schnell
in 6 umbenannt worden ist) benutzen sie einen völlig anderen Debugger.

J.G. S. schrieb:
> Aber leider macht der ums verrecken keine langen
> CALLs wenn man ihm etwas grösseren C/ASM Mix unterschiebt.

Hast Du mal ein Beispiel?
Ich habe kein Probleme, *.c mit *.S zusammen zu compilieren und zu 
linken.

Jörg W. schrieb:
> Joachim B. schrieb:
>> oder gibt es den Fehler da auch?
>
> Gegenfrage: warum sollte es den dort nicht geben?  Benutzt doch
> schließlich einen gleichermaßen handgestrickten DWARF-Parser.

wenn du es weisst musst du ja keine Gegenfrage stellen.

Bei mir klappte was mmit dem 4.19 nicht und ich bin reuemütig zum 4.18 
zurückgekehrt, der 6er hat meine PC so ausgebremst, das machte keinen 
Spass.

Joachim B. schrieb:
> Bei mir klappte was mmit dem 4.19 nicht und ich bin reuemütig zum 4.18
> zurückgekehrt

Ich hätte nur arge Zweifel daran, dass sich ausgerechnet dieser
handgefeilte DWARF-Parser zwischen den beiden Versionen so massiv
unterscheiden würde.

Das war ansonsten aber keinesfalls als Verallgemeinerung gedacht.

Jörg W. schrieb:
> ch hätte nur arge Zweifel daran, dass sich ausgerechnet dieser
> handgefeilte DWARF-Parser zwischen den beiden Versionen so massiv
> unterscheiden würde.

was es genau war weiss ich nicht, aber hier gab es Beiträge das auch 
andere mit 4.19 "Kummer" hatten und unisono behauptet wurde der 4.18 
läuft besser was ich aus eigener Erfahrung bestätigen kann.

Ich hatte ja mein Projekt mit 4.18 sp3 erfolgreich compiliert. Der obige 
Fehler trat da nicht auf. Kann mich aber nicht mehr an die 
Umgebungsparameter erinnern, war alles Standard irgendwie.
Beim Wechsel auf 4.19 compilierte er alles fast sofort richtig. Einzig 
wollte er das ich Flashtabellen als const definiere, naja gut ....
Per ISP reingebrannt lief auch alles wie es sollte, nur eben beim 
Debuggen stürzte das Studio ab. Könnt euch sicher vorstellen wo man da 
anfängt Fehler zu suchen, ohne Anhaltspunkte. Es war etwa 20K gross das 
Prg.

Ein Beispiel für die langen CALLs (bzw. JMPs) hab ich leider nicht. Es 
muss schon alles sehr gross werden. Reiner C-Code funktioniert 
natürlich, auch bei nem C / ASM mix wenn die Sprungdistanz nicht zu 
gross wird. Aber wenn der Linker abwechselnd .c .s .c. .s ... zusammen 
knoten muss und ausserdem häufig weit hin und her springen muss, dann 
scheint er nicht richtig die Distanz ermitteln zu können, da sich ja 
auch die Prg.länge mit jedem absoluten CALL/JMP ändert und er wieder von 
vorn anfangen muss. Er meldet dann so sinngemäß .. Interner Fehler, 
Sprungziel ausserhalb des Bereichs.
 Er konnte dann nicht mal eine am Ende stehende asm/Interruptroutine 
vorn in der Interrupttabelle eintragen, obwohl die ja 4Byte Platz für 
absolute JMPs hat. (atmega328)

Das dürfte aber kaum was mit der Version des AVR Studio zu tun haben,
sondern damit, dass sie eine neuere Toolchain dann mitgeliefert
haben.

Allerdings ist es natürlich schon seltsam, wenn ihnen der Debugger
bereits mit den DWARF-Symbolen abstürzt, die die mitgelieferte
Toolchain liefert.  Solche Effekte hätte ich eher dann erwartet, wenn
man nachträglich extern eine neuere Toolchain dranhängt (was ja an
sich keine schlechte Idee wäre).

Jörg W. schrieb:
> Das dürfte aber kaum was mit der Version des AVR Studio zu tun haben,
> sondern damit, dass sie eine neuere Toolchain dann mitgeliefert
> haben.

So wird es sein.
Bei 4.18 müsste ich die toolchain 3.4.1.1195 benutzt haben 
(wahrscheinlich)


Ohh sehe gerade oben bei meinem ersten Beitrag habe ich die falsche 
toolchain angegben, da hatte ich Version 3.4.2.1573 .  Mist