Es ist wirklich schade das man den LLVM/clang noch nicht so ohne weiteres für das kompilieren des Kernels verwenden kann denn dann hätte man jetzt wenigstens einen alternativen Compiler zur Hand.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jul 2014 um 10:24.
Das habe ich ja auch nicht bestritten - aber nur weil es dann eine Alternative gäbe, wäre das nicht unbedingt automatisch für solche Situationen eine Lösung
Grundsätzlich gebe ich Dir aber recht, dass es wünschenswert und nützlich wäre.
Da habt ihr mir aber fast einen Schrecken eingejagt, mit dieser Lachsen Formulierung:
"Der Fehler von GCC besteht darin, dass er die Option -mno-red-zone unter bestimmten Umständen, beispielsweise bei einer Optimierung auf Code-Größe, missachtet. Diese Optimierung wird für den Kernel mittlerweile nicht mehr empfohlen, eine Zeitlang war das allerdings der Fall." Gepaart mit dem Hinweis, welche GCC Versionen alle betroffen sind.
Bis mir dann klar wurde, dass das Problem also nur auftritt, wenn man seinen Kernel mit der GCC Optimierungsstufe Os statt O2 übersetzt. Ich kenne es nicht anders, als das O2 die standard Optimierungsstufe fürs kernel übersetzen ist. Wann war das denn mal anders - kann das jemand konkret benennen?
Für meine ausschließlich selbst erstellten Kernel, bedeutet das jedenfalls Entwarnung, auch brauch ich mit den fehlerbereinigten GCC-Versionen nichts Rekompilieren - alles halb so wild, also.
War mal wieder ein Warnschuss vor den Bug all derjenigen, die ihren Kernel mit allzu aggressiven CFLAGS übersetzen wollen, so wie wir Gentoo-User das ja auch gerne mal für alle anderen Pakete machen. Auch ich hab mich in der Vergangenheit schon mal daran versucht, den Kernel z.B. mit LTO u.a. Flags zu übersetzen.
Nun muss ich Linus aber mal wieder recht darin geben, den Kernel standardmäßig mit konservativeren Einstellungen zu übersetzen, man sieht ja wohin das führen kann.
Eigentlich waren hier keine besonders aggressiven Optionen am Start. Es war eben ein Fehler, wie er immer mal vorkommen kann. Ich hoffe mal, dass mit der Korrektur auch ein Testfall geschaffen wurde, so dass sich dieser Fehler nicht mehr einschleichen kann.
hab ja auch nicht gesagt, dass hier aggressive Optionen genutzt wurden, nur dass ich mich schon mal damit beschäftigt habe. ;-) Wenn man sich nun vor Augen hält, wie lange das unentdeckt blieb, kann ich Linus konservative Haltung gegenüber aggressiven Flags verstehen, wenn es um den Kernel geht.
Sorry falls ihr darüber auch berichtet hattet, konnte es jedoch nicht finden, daher der Link zu Golem diesbezüglich: http://www.golem.de/news/linux-kernel-lto-patch-entfacht-diskussion-1404-105731.html
Ansonsten teile ich deine Hoffnung und Schlussfolgerung.
Os ist meines Wissens nach weniger aggressiv als O2 bei der Optimierung. Es macht alles was O2 auch macht, aber lässt Optimierungen weg die zu größerem Code führen. Os als Optimierung wurde mal für eingebettete Systeme und Systeme mit kleinen Caches empfohlen.
Deine Aussage stimmt zwar, da Os gegenüber O2 folgendes deaktiviert: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version
Dennoch stellt es eben eine Abweichung von den bewährten Standard-Settings dar und hier sieht man halt schön warum man gut daran tut, nicht davon abzuweichen.
Übrigens, auf nicht embedded Systemen ohne allzu kleinen Speicher, stellt O2 immer noch den besten Kompromiss zwischen Performance, Speicherverbrauch und Stabilität dar. Ein Beispiel: http://www.linux-mag.com/id/7574/ Siehe auch Conclusion am Ende des Artikels, wer nicht alles Lesen möchte.
Es ist wirklich schade das man den LLVM/clang noch nicht so ohne weiteres für das kompilieren des Kernels verwenden kann denn dann hätte man jetzt wenigstens einen alternativen Compiler zur Hand.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jul 2014 um 10:24.Der dann natürlich wieder andere Fehler beinhaltet...
Wäre trotzdem von Vorteil. Wenn man die Kompilate von beiden Compilern vergleicht, dann findet man vielleicht Fehler die sonst Verdeckt sind.
Das habe ich ja auch nicht bestritten - aber nur weil es dann eine Alternative gäbe, wäre das nicht unbedingt automatisch für solche Situationen eine Lösung
Grundsätzlich gebe ich Dir aber recht, dass es wünschenswert und nützlich wäre.
So ein Quark, Fehler wird es immer geben.
Da habt ihr mir aber fast einen Schrecken eingejagt, mit dieser Lachsen Formulierung:
"Der Fehler von GCC besteht darin, dass er die Option -mno-red-zone unter bestimmten Umständen, beispielsweise bei einer Optimierung auf Code-Größe, missachtet. Diese Optimierung wird für den Kernel mittlerweile nicht mehr empfohlen, eine Zeitlang war das allerdings der Fall."
Gepaart mit dem Hinweis, welche GCC Versionen alle betroffen sind.
Bis mir dann klar wurde, dass das Problem also nur auftritt, wenn man seinen Kernel mit der GCC Optimierungsstufe Os statt O2 übersetzt. Ich kenne es nicht anders, als das O2 die standard Optimierungsstufe fürs kernel übersetzen ist. Wann war das denn mal anders - kann das jemand konkret benennen?
Für meine ausschließlich selbst erstellten Kernel, bedeutet das jedenfalls Entwarnung, auch brauch ich mit den fehlerbereinigten GCC-Versionen nichts Rekompilieren - alles halb so wild, also.
War mal wieder ein Warnschuss vor den Bug all derjenigen, die ihren Kernel mit allzu aggressiven CFLAGS übersetzen wollen, so wie wir Gentoo-User das ja auch gerne mal für alle anderen Pakete machen. Auch ich hab mich in der Vergangenheit schon mal daran versucht, den Kernel z.B. mit LTO u.a. Flags zu übersetzen.
Nun muss ich Linus aber mal wieder recht darin geben, den Kernel standardmäßig mit konservativeren Einstellungen zu übersetzen, man sieht ja wohin das führen kann.
Beruhigenden Gruß, Andy.
Sehr guter Kommentar!
Eigentlich waren hier keine besonders aggressiven Optionen am Start. Es war eben ein Fehler, wie er immer mal vorkommen kann. Ich hoffe mal, dass mit der Korrektur auch ein Testfall geschaffen wurde, so dass sich dieser Fehler nicht mehr einschleichen kann.
Genau hjb,
hab ja auch nicht gesagt, dass hier aggressive Optionen genutzt wurden, nur dass ich mich schon mal damit beschäftigt habe. ;-)
Wenn man sich nun vor Augen hält, wie lange das unentdeckt blieb, kann ich Linus konservative Haltung gegenüber aggressiven Flags verstehen, wenn es um den Kernel geht.
Sorry falls ihr darüber auch berichtet hattet, konnte es jedoch nicht finden, daher der Link zu Golem diesbezüglich:
http://www.golem.de/news/linux-kernel-lto-patch-entfacht-diskussion-1404-105731.html
Ansonsten teile ich deine Hoffnung und Schlussfolgerung.
Gruß, Andy.
Os ist meines Wissens nach weniger aggressiv als O2 bei der Optimierung. Es macht alles was O2 auch macht, aber lässt Optimierungen weg die zu größerem Code führen. Os als Optimierung wurde mal für eingebettete Systeme und Systeme mit kleinen Caches empfohlen.
Deine Aussage stimmt zwar, da Os gegenüber O2 folgendes deaktiviert:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -freorder-blocks-and-partition
-fprefetch-loop-arrays -ftree-vect-loop-version
Dennoch stellt es eben eine Abweichung von den bewährten Standard-Settings dar und hier sieht man halt schön warum man gut daran tut, nicht davon abzuweichen.
Übrigens, auf nicht embedded Systemen ohne allzu kleinen Speicher, stellt O2 immer noch den besten Kompromiss zwischen Performance, Speicherverbrauch und Stabilität dar. Ein Beispiel:
http://www.linux-mag.com/id/7574/
Siehe auch Conclusion am Ende des Artikels, wer nicht alles Lesen möchte.
CONFIG_CC_OPTIMIZE_FOR_SIZE
zu finden unter "General setup"