Ich hab da ein problem mit dem GCC (Feb2005) und AVR Studio (4.10): Ich schreibe meinen Code gerne auf mehrere Dateien (nach Funktionsgruppen) verteilt. Daraus folgt ein Problem: Die Datei main.c wird noch richtig debuggt, aber sobald er in eine Fkt. springen soll, die in einer anderen Datei liegt, startet er den Debugger und zeigt nur den Assemblercode an. Lustiger weise kann's auch mal sein, dass er eine Datei öffnen will, in der aber nur wild herumspringt ohne irgendwelchen Sinn... Weiß jemand, woran das liegen kann?
Zur Klärung. Die Funktionen liegen entweder im selben Vwerzeichnis, eingebunden als #include"", oder auch in einer gebundenen Lib libavrso.a, die mittels -l an den Linker übergeben wird... Bei beiden taucht das selbe Problem auf :(
Wenn die Source-Dateien per #include eingebunden werden, dann ist das auch kein Wunder. Bedenke, daß die Auswertung von Headerdateien auf reiner Textebene geschieht - ob Du main.c mit #includes übersetzt oder aber statt der #includes deren Inhalt an die betreffende Stelle in main.c einfügst, ist für den Compiler exakt dasselbe. Die Objektdatei, die der Compiler erzeugt, enthält als Debughilfe nur die Informationen über Zeilennummern, definierte Symbole etc, nicht aber Dateinamen. Somit sind alle von Dir verwendeten Symbole in der aus main.c erzeugten Objektdatei definiert; anhand eines Symbolnamens kann der Debugger aber nicht mehr Wenn Du modular programmieren willst, dann solltest Du es "richtig" anstellen: Jedes Modul (*.c-Sourcefile) wird getrennt zu einer Objektdatei übersetzt, diese werden gelinkt. Damit Du aus einem Modul Funktionen oder Definitionen eines anderen Modules verwenden kannst, erzeugst Du für jedes Modul eine gleichnamige Headerdatei, in der Du die extern sichtbaren Prototypen etc. deklarierst. Dadurch bleibt die Zuordnung Objektdateiname-Symbol erhalten. Wenn Du eine Library verwendest, muss diese Library bereits sämtliche Debuginformationen enthalten; sonst weiss der Linker auch nicht mehr, aus welchen Sourcemodulen die Library besteht. Wenn die Library ebenfalls durch #include von Sourcefiles erzeugt wurde, dann gilt obengesagtes.
Das Problem ist zwar nicht gelöst, aber umgangen. Wenn man anstelle des extcoffs eine dwarf-2 .elf-Datei generiert funktioniert alles wie es soll. Nur benötigt man für dwarf-2 ein AVR Studio 4.10 oder höher
Hallo Dirk, wie lauten denn Deine Compiler/Linker/dwarf-Konverteranweisungen? Gruß Martin
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.