Servus!
Unter
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.4/
ist ja mit der Datei
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.4/avr-libc-1.8.0.tar.bz2
der Sourcecode der libc erhältlich.
Beim Studio 5 & 6 bzw. gibt es ja durch Visualstudio per Alt+G bzw.
Rechtsklick "Goto Implementation" die Möglichkeit sich den Source einer
Funktion anzeigen zu lassen.
Ich habe jetzt den Inhalt des Ordners libc\avr-libc\ in dieser Datei
nach
C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8
GCC\Native\3.4.1056\avr8-gnu-toolchain\avr
entpackt, weil ich da jeweils identische Dateien gefunden habe. (die
Header)
Der Ordner gilt jetzt fürs Studio 6, ist aber beim 5er ähnlich.
Kennt ihr eine Möglichkeit dem Studio nun mitzuteilen, dass es dort nach
den Sources suchen soll? (wenn es unter Code::Blocks irgendwie möglich
wäre, würde ich mich auch sehr freuen)
lG,
Daniel
Daniel A. Maierhofer schrieb:> Kennt ihr eine Möglichkeit dem Studio nun mitzuteilen, dass es dort nach> den Sources suchen soll?
Da wirst du wohl die ganze avr-libc mit Debuginformationen compilieren
und installieren müssen.
Danke für die rasche Antwort Jörg!
Ich hab zwar schon mit MinGW32 und dem Compilieren einiger Libraries
(welche ohne MSYS installierbar waren, wie z.B. die Allegro Game
Programming Library) Erfahrung, aber leider weiß ich da nicht ganz, wie
ich da ansetzen soll das in einer Debug-Version zu compilieren?
./configure kann ich ja unter Windows nicht so leicht ausführen. ;)
Wobei, es geht mir gar nicht darum Beim Debuggen bis in die niedrigste
Implementierungsstufe zu kommen, mir würde es völlig reichen mit "Goto
Implementation" da bequem hinzufinden.
Ich habe wie unter
Beitrag "Arduino Library unter Atmel Studio 6.2"
beschrieben z.B. die komplette Arduino-Library als statisch linkbare
Library compiliert und kann bei dem Beispielprogramm ohne Probleme mit
Alt+G bzw. Goto Implementation bis ins kleinste Detail nachverfolgen,
was unter der Haube der Library vor sich geht.
Genau so hätte ich es gern mit der avr-libc, wobei ich mich nicht ganz
herantrau, die im AVRStudio komplett einbinden zu können. :)
Oder ist das die einzige Möglichkeit diese Informationen der IDE
mitzuteilen? Soweit ich das verstehe können in den .o Files "Symbole"
enthalten sein, welche die Namen der Variablen & Funktionen
widerspiegeln.
In diesem Fall interessier ich mich aber ja gar nicht für die bereits
kompilierten Sachen sondern ich will gern im Source herumspringen
können.
Daniel A. Maierhofer schrieb:> ./configure kann ich ja unter Windows nicht so leicht ausführen. ;)
Doch, MinGW32 liefert eine Bash mit. Anders kann die avr-libc, die
Atmel mitliefert, ja auch nicht entstanden sein (sofern sie sie nicht
gerade auf Unix compilieren, danach strip -g, das würde auch gehen ;-).
> Soweit ich das verstehe können in den .o Files "Symbole"> enthalten sein, welche die Namen der Variablen & Funktionen> widerspiegeln.
Es sind lediglich die Symbole noch vorhanden, die der Linker
unbedingt braucht. Also schon interne Funktionen wirst du nicht
mehr finden.
Allerdings enthalten halt die Debugsymbole den Hinweis auf den
Dateinamen, der ohne diese logischerweise fehlt. Keine Ahnung, ob
das Atmel Studio auch ohne diese Info in der Lage ist, dass du ihm
mitteilen kannst, welche Quelldatei zu welchem Objektmodul gehört.
Daniel A. Maierhofer schrieb:> ./configure kann ich ja unter Windows nicht so leicht ausführen. ;)
Brauchst du auch nicht. Die avr-libc enthält ja code für AVR, nicht für
Windwos :-) Du kannst die Lib also auch unter Linux erzeugen und unter
Windows verwenden.
Johann L. schrieb:> Du kannst die Lib also auch unter Linux erzeugen und unter Windows> verwenden.
Allerdings stimmen dann die Pfadnamen im DWARF-2 nicht mehr. Gerade
die sind ja hier aber wichtig.
Jörg Wunsch schrieb:> Da wirst du wohl die ganze avr-libc mit Debuginformationen compilieren> und installieren müssen.Jörg Wunsch schrieb:> Allerdings stimmen dann die Pfadnamen im DWARF-2 nicht mehr. Gerade> die sind ja hier aber wichtig.
Sorry Jörg, aber ich bezweifle stark, dass das dem OP weiterhilft. Es
geht hier ja nicht um den Debugger, sondern um den Source-Code-Editor
der IDE. Der sucht einfach in dem ihm zur Verfügung stehenden
Source-Code nach der Funktionsdefinition. Für das, was der OP möchte,
müsste man den Source-Code der Lib dem Projekt als eine Art externe
Referenz/Abhängigkeit hinzufügen, so dass er zwar bei der
Source-Code-Analyse mit berücksichtigt wird, aber nicht mit
kompiliert/gelinkt wird.
Ich weiß aber auch nicht, ob und wie das beim Studio geht.
Stefan Ernst schrieb:> Es geht hier ja nicht um den Debugger, sondern um den Source-Code-Editor> der IDE. Der sucht einfach in dem ihm zur Verfügung stehenden> Source-Code nach der Funktionsdefinition.
Zumindest im alten AVR Studio hat er aber Dateien, die keine
Dateinamensinformationen in den Debug-Infos hatten, komplett
ignoriert und kam nie auf die Idee, dafür irgendwo nach dem
Sourcecode zu suchen. (Wurde die Datei nicht an der in den
Debug-Infos hinterlegten Stelle gefunden, wurde explizit nach dem
Standort gefragt.)
Keine Ahnung, ob das mit dem Visual-Kram jetzt tatsächlich völlig
anders ist. Ich benutze das Zeug nur, wenn mich jemand mit Geld
dafür bedroht. ;-)
Stefan Ernst schrieb:> Für das, was der OP möchte,> müsste man den Source-Code der Lib dem Projekt als eine Art externe> Referenz/Abhängigkeit hinzufügen, so dass er zwar bei der> Source-Code-Analyse mit berücksichtigt wird, aber nicht mit> kompiliert/gelinkt wird.
Ich hab grad gesehn, dass ich mir die Lösung des "Problems" heut schon
vorweggenommen habe!
siehe Beitrag "Arduino Library unter Atmel Studio 6.2"
Vorgehensweise:
Neues GCC C Static Library Project erstellen, die Startdatei rauslöschen
und alle .c .h sowie .S und .inc Files aus folgenden Verzeichnissen als
Vorhandenes Element als Link hinzugefügen
Ihr müsst halt den Pfad bei Verwendung einer anderen Version der
Toolchain anpassen.
Dann noch bei den Projekteigenschaften für alle Konfigurationen unter
Toolchain dem AVR/GNU C Compiler sowie Assembler mitgeteilt, dass er
auch im Verzeichnis (kein Relativer Pfad!)
nach Includes, in dem Fall asmdef.h suchen soll.
Bis auf ein einziges Warning für \avr\libc\stdlib\dtostre.c kompiliert
das dann einwandfrei unter dem Atmel Studio 6.2 bei der Vorgehensweise!
Wobei das Kompilieren eigentlich gar nicht notwendig ist.
-> Im Konfigurationsmanager das Häkchen beim Erstellen weggeben. Voillà!
Das Projekt kann man dann bei einer zu untersuchenden Projektmappe *als
vorhandenes Projekt hinzufügen* und den ganzen Source durchstöbern!
Anbei das "Projekt".
Daniel A. Maierhofer
Du weißt aber, dass die avr-libc in vielen Variationen compiliert
wird für die einzelnen AVRs, ja? Nicht alle werden dabei den gleichen
Objektcode haben (sonst wären die Variationen nicht nötig).
Wenn du dir die Implementierungsdateien nur ansehen willst, ist das
sicher ziemlich egal, aber sowas wie Single-Step wird auf diese Weise
sicher nicht gelingen.
Hab gerade gemerkt, dass ich auf die AVR-spezifischen Includes vergessen
habe, also die Sources aus folgenden Orndern müssen ebenfalls
hinzugefügt werden:
Außerdem waren das leider alles relative Pfade, sodass es nur in einer
bestimmten Verzeichnisebene funktionierte. Jetzt sollte es überall
funktionieren wo die jetzt gerade aktuelle Toolchain 3.4.1056
installiert ist. Ansonsten einfach per Texteditor ersetzen.
Anbei das aktualisierte File. Kompilieren dauert bei dem, wenn man es
spaßeshalber probiert, schon eine halbe Ewigkeit, dafür aber eine
vollkommen klaglose.
Jörg Wunsch schrieb:> Du weißt aber, dass die avr-libc in vielen Variationen compiliert> wird für die einzelnen AVRs, ja? Nicht alle werden dabei den gleichen> Objektcode haben (sonst wären die Variationen nicht nötig).
Ja genau, das hab ich eben auch gemerkt, weil ich die ganzen io-Files
noch gar nicht inkludiert hatte.
> Wenn du dir die Implementierungsdateien nur ansehen willst, ist das> sicher ziemlich egal, aber sowas wie Single-Step wird auf diese Weise> sicher nicht gelingen.
Denk mir auch, dass das nicht einfach sein kann, aber mir reichts auf
C-Sourcecodeebene. In speziellen Fällen kann ich mir ja eh das
Assemblerlisting anschaun.
