Login
Newsletter
Werbung

Thema: Fehler in GCC kann falschen Kernel-Code erzeugen

18 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von schmidicom am Mo, 28. Juli 2014 um 10:07 #

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.
[
| Versenden | Drucken ]
2
Von Randy Andy am Mo, 28. Juli 2014 um 13:22 #

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.

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Mo, 28. Juli 2014 um 14:39 #

    Sehr guter Kommentar! :up:

    [
    | Versenden | Drucken ]
    0
    Von hjb am Mo, 28. Juli 2014 um 15:15 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von Randy Andy am Mo, 28. Juli 2014 um 17:15 #

      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.

      [
      | Versenden | Drucken ]
    0
    Von Unerkannt am Mo, 28. Juli 2014 um 16:32 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von Randy Andy am Mo, 28. Juli 2014 um 17:26 #

      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.

      [
      | Versenden | Drucken ]
    0
    Von funtoo am Mo, 28. Juli 2014 um 18:21 #

    CONFIG_CC_OPTIMIZE_FOR_SIZE
    zu finden unter "General setup"

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung