Hallo, in die Runde gefragt. Muss ich mir irgendwelche Sorgen machen bei den DWARF Fehlern? Beim eigentlichen kompilieren ist ja alles ok. Die Fehler kommen doch nur vom Debugger? Kann ich die ignorieren? Oder wird das irgendwie kritisch? Es begann ab einer bestimmten Codegröße.
Veit D. schrieb: > Die Fehler kommen doch nur vom Debugger? Sie kommen vom Disassembler. Ich würde aus dem Gewusel vieles, sehr vieles einfach rauswerfen – weil es Quatsch ist, das jedesmal alles überhaupt anzuwerfen. Diese Disassembler-Listings werden eh total überbewertet. Die Optimierungen des Compilers verwürfeln den Code hinreichend gut, als dass der Versuch, da noch zeilenweise den Sourcecode zuzuordnen, eher schlecht als recht funktioniert. Wenn du wirklich wissen willst, was passiert, geht um das Verständnis des tatsächlich erzeugten Maschinencodes nichts herum, und den Sourcecode dazu schaust du dir besser in einem zweiten Fenster parallel an. Nichtsdestotrotz hat entweder der Compiler oder das objdump hier ein Problem. Offsets, die ins Nirvana zeigen, sollte es natürlich nicht geben.
Hallo, wenn ich dich richtig verstehe ist das nur ein Disassemblierungsproblem. Der übersetzte Code ist ok. Denn hierbei hatte ich dann langsam Bedenken. objdump habe ich schon "ausgeschalten". Sonst hätte ich die 2 Zeilen ein Drittesmal. Was meinst du mit "im Gewusel" ausschalten?
Hallo, ich hatte mich schon gewundert woher die Ausgabe vom objdump kommt wenn ich meine ausgeschalten hatte. In den Einstellungen des DxCore ist das auch drin. Übrigens erstellt der avr-gcc 12.3 nur eine Fehlermeldung statt 2.
Veit D. schrieb: > objdump habe ich schon "ausgeschalten" In deinem Log ist es noch einmal drin, als avr-objdump -d -S (ok, mit den Langformen der Optionen). Das disassembliert den Code (-d) und versucht, anhand der Debuginformationen den Sourcecode aus den Quelldateien zu den einzelnen Bereichen zuzuordnen (-S). Beim avr-nm tritt der gleiche Fehler nochmal auf, weil auch da Zeilennummerninformationen erfragt werden und daher die Debug-Infos gelesen werden müssen. Da sowohl objdump als auch nm auf das gleiche Backend (libbfd) zurückgreifen, ist es natürlich wenig verwunderlich, dass sie über die ihrer Meinung nach gleiche Inkonsistenz in den Debug-Informationen klagen. Ob nun tatsächlich der Compiler Fehler in den Debug-Infos generiert hat oder libbfd bloß irgendwas falsch interpretiert, kann man natürlich ohne tiefe Analyse nicht feststellen. Aber sicher ist, dass es nichts mit dem Code selbst sondern nur mit der Debug-Info ist.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.