|
Anzeige
|
AVR: ISR mit internal linkage: keine Linker-Fehlermeldung
Gast
#7307292
Deklariere ich eine ISR fälschlicherweise mit internal linkage
so hätte ich eigentlich eine Warnung vom Linker erwartet, dass die Funktion dann nicht in den Interrupt-Vektor eingetragen wird. Kommt aber leider nicht. Bitte keine Kommentare, dass das natürlich falsch ist: weiß ich doch. Ich möchte nur verstehen, warum da keine Fehlermeldung kommt bzw. wie ich eine Meldung bekommen könnte.
Gast
#7307302
Woher soll der Linker wissen, dass du versucht hast eine ISR zu implementieren? Es fehlt Attribut "externally_visible".
Gast
#7307316
Aber die Antwort. Oliver
Gast
#7307322
Ja. Du hast es halt falsch gemacht. Warum sollte der Linker Heuristiken haben, die sowas erkennen? Du hast halt eine lokale Funktion implementiert und keine ISR. Mache es richtig, dann funktioniert es auch.
Aus Linkersicht ist alles in Ordnung, denn er hat default-Vektoren für alles. Wenn, hätte der Compiler eine Chance, das anzumerken. Er sieht, dass du _vector* definierst und er sieht auch, dass das nicht global ist. Hat eben nur keiner einen Test dafür im Compiler implementiert bislang. Das Problem ist, dass der Code ohne externally_visible falsch ist. Und mit externally_visible, kommt der Code erst garnicht zum Linker (da static). Bevor du Warnungen vom Linker erwartest (die es nicht gibt) mach erst mal korrekten C/C++ Code. Sowas gehört eh in einen System-Header, und wenn man die falsch hat, hat man nunmal schlechte Karten. Daher nimmt man ISR aus avr/interrupt.h der AVR-LibC als include oder als Vorlage für einen eigenen System-Header. Ohne externally_visible dürfen Optimizer die Funktion in eine lokale umwandeln, und die wird nie in einer IRQ-Tabelle auftauchen. Daher ist der Code ohne externally_visible nicht korrekt.
Gast
#7307331
Gibt es in den üblichen AVR-Toolchains nicht ein extra Marko wie ISR() genau dafür? Dessen Nutzung ersparte manuelle Fehler.
Gast
#7307334
Ja, sowas hatte ich erwartet ;-)
Ok, das wusste ich nicht. D.h. ein Optimizer darf external-linkage zu internal-linkage ändern. Kann doch aber nur bei LTO gemacht werden, oder?
Gast
#7307338
Und Leute, spart Euch die Hinweise, dass das falsch ist:
Gast
#7307352
Du hast es doch gar nicht als external-linkage angegeben.
Gast
#7307363
Naja, deine Frage ist eben: Ich mache X, will aber Y. Warum warnt der Compiler/Linker mich nicht? Und ja, diese Frage kann man stellen und sie ist auch oft angebracht. Aber in diesem Fall eher nicht. Das hier ist ein Superspezialfall, wenn du deine eigenen Systemheader selbst neu implementierst. Nutze einfach die ISR-Makros aus deinen Systemheadern und gut ist. Deshalb ist hier die Antwort: Du machst es halt falsch.
Das umfasst alle globalen Optimierungen, nicht nur LTO.
Erweiter ./gcc/config/avr/avr.cc::avr_set_current_function() oder ähnliche Stellen, die dafür geeignet sind.
Gast
#7307397
Wie kann der Optimierer beim Übersetzen einer TU entscheiden, das external-linkage zu internal-linkage geändert werden darf, wenn nicht LTO verwendet wird?
Gast
#7307413
Gar nicht. Und das ist, wie gesagt, ja auch gar nicht, was hier passiert. Die Funktion hatte nie external-linkage.
Gast
#7307434
Wir sind hier in der Diskussion ja schon einen Schritt weiter: natürlich schließen sich
Daher verstehe ich Johann so, dass non-static Funktionen (external linkage) zu internal linkage umgewandelt werden können, sofern kein externally_visible angegeben ist. Und das erscheint mir unverständlich.
Gast
#7307461
Das kann es nur mit LTO (und je nachdem noch whole program optimization).
Gast
#7307464
Genau das war doch auch meine Vermutung. Johann scheint da anderer Meinung zu sein. Wie gesagt, alle globalen Optimierungen: -flto, -fwhole-program. oder wie die heißen mögen, z.b. bei clang/llvm. Prinzipiell ist es keine gute Idee, die Korrektheit eines Programms von Optimierungen abhängig zu machen. Für vanilla C/C++ kann das nur bedeuten, dass das Programm UB ist oder ill-formed. Bei Features jenseits des Standards wie __asm oder Attributen muss man sich eben an das halten, was die Toolchain vorgibt, auch wenn sie nicht für jeden unsinnigen Code explizit austextet, dass er unsinnig ist. Ich versteh auch nicht, worüber noch groß diskutiert wird und Unklarheit besteht. Du kannst
Code wie im OP wird man doch ohnehin in einen Convenience Header / Makro verstecken wollen, so dass die Chance einer falschen Verwendung minimiert wird.
Gast
#7307529
Ok, gut. Dann ist es also so, wie ich es vermutet habe: das LTO stand für mich pars-pro-toto.
Es bestand keine Unklarheit - jedenfalls nicht bei mir, das habe ich oben auch schon geschrieben. Lediglich habe ich mich gewundert, dass bei meinem mutwillig falschen Code, keine Warnung entstand. Das war alles.
Nö. Es war reine Neugier zu erfahren, warum die Dinge so sind, wie sie eben sind.
Nö.
Klaro.
Vielleicht.
Na klar, habe auch nichts anderes behauptet. Es war ja reine Neugier, was dort passiert und warum da keine Warnung kam. Nun ist es geklärt - es ist einfach nicht realisiert. Gut, kann man natürlich einbauen, eine Diagnostic dass "externally_visible" erforderlich ist wenn Attribut "interrupt" und/oder "signal" vorhanden sind. Auf die Linkage zu testen würde nicht funktionieren. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
