Endlos-Reboot Images mit OpenSuSe 11.3 (mksquashfs Fehler)

[schmatke]

off-topic:
@olistudent
Beim 1. mal dachte ich: vertippt, aber das war jetzt glaube ich das 3. mal schmattke mit 2t. Bitte nur mit 1t.
MfG Schmatke

 

[RalfFriedl]

Du brauchst nicht gleich ein komplettes Image zu erstellen. Zum Testen habe ich nur einige kleine Dateien angelegt und mit mksquashfs3-lzma ein Dateisystem erstellt. Mit "unsquashfs3-lzma -ll" kann man sich den Inhalt ansehen. Im einen Fall kommt das Hauptverzeichnis mit den Einträgen, im anderen Fall nur das Hauptverzeichnis, danach nichts mehr.

Eine Floating Point Exception hatte ich auch nicht.

Das Problem könnte mit memcpy zusammenhängen, allerdings nicht mit den beiden im Changelog erwähnten. Der Compiler generiert Anweisungen, die unmittelbar nacheinander eine 32-Bit Null an eine Adresse schreiben und dann direkt auf die folgende, ungerade Adresse, so daß sich die beiden Bereiche überlappen, was für sich allein schon unsinnig ist, ganz zu schweigen davon, daß dahin nunmal keine Null gehört, sondern der bereits dort stehende, richtige Wert überschrieben wird.

Was mich auch wundert ist, daß der Compiler über 64kB als Stack für die Funktion reserviert, aber das tut der ältere Compiler auch, und bei dem funktioniert das Programm. Ich gehe davon aus, daß die Optimierung durch die Swap-Zweige in der Funktion durcheinander gebracht wird. Die Makros sehen zwar schön übersichtlich aus, aber die Anweisungen, die sich dahinter verbergen, sind doch recht lang. Was natürlich trotzdem kein Grund ist, falschen Code zu erzeugen.

PS:
Ich habe hier noch etwas interessantes gefunden:

Casting does not work as expected when optimization is turned on.

This is often caused by a violation of aliasing rules, which are part of the ISO C standard. These rules say that a program is invalid if you try to access a variable through a pointer of an incompatible type. ...
To disable optimizations based on alias-analysis for faulty legacy code, the option -fno-strict-aliasing can be used as a work-around.

Vielleicht liegt der Fehler auch nicht am Compiler. Wenn ich dazu komme, probiere ich mal die Option -fno-strict-aliasing aus.

 

[olistudent]

Mit "-fno-strict-aliasing" hab ich das Problem immer noch. Wenn ich in dem Abschnitt "SQUASHFS_LREG_TYPE" die memcpys durch memmoves ersetze, dann bekomm ich mit unsquashfs die Dateien angezeigt. Komischerweise wird dieser Teil der Schleife bei mir nie aufgerufen!? Zumindest landen die Zeilen mit TRACE nicht in meinem Log (ich hab das trace durch printf ersetzt). Oder landet nur die Ausgabe wo anders?

MfG Oliver

 

[schmatke]

Hat schon jemand mit einer anderen Linux-Distribution (nicht OpenSUSE >/=11.3) die gcc 4.5 hat, ein brauchbares Freetz-Image compiliert?

Ja, mit Ubuntu 10.10

- Linux freetz-desktop 2.6.35-19-generic #28-Ubuntu SMP Sun Aug 29 06:34:38 UTC 2010 x86_64 GNU/Linux
- gcc (Ubuntu/Linaro 4.5.1-5ubuntu1) 4.5.1

 

[sf3978]

Danke für die Info. Dann schlussfolgere ich für mich, dass es nicht am gcc4.5 liegt, sondern evtl. doch etwas mit OpenSUSE 11.3 zu tun hat. Ich bleibe erstmal bei OpenSUSE 11.2.

 

[Silent-Tears]

Zumindest die Ubuntu-Version ist eine beta, da die 10.10 Ende Oktober rauskommen wird. Von daher ist alle,s was solche Versionen angeht, eher ein Ratespiel, was denn da zum Schluss passiert oder auch nicht. Die Suse allerdings ist eine Release-Version, anscheinend auf einem aktuellen Updatestand. Da kann man evtl mal bei Suse anklopfen, was die denn anders machen mit ihren Einstellungen.

 

[schmatke]

Ubuntu 10.10 Nachtrag:
Wobei ich vielleicht noch erwähnen sollte, dass der gcc4.4 auch noch drauf ist. Ich glaube libtool wollte das unbedingt.
Ich hab dann nur /usr/bin/gcc auf den gcc4.5 gelinkt. Und den gcc++ hatte ich nur in V.4.4 gefunden. Keine Ahnung, welche Rolle das evtl. spielt...

PS:
Mein suse 11.3 ist natürlich auf einem aktuellen Updatestand. ;-)

 

[RalfFriedl]

Da es inzwischen recht deutlich ist, daß es am GCC von SUSE 11.3 liegt, könnte das mal jemand im Titel ergänzen? Das Problem wird nicht nur die 7240 betreffen.

Mit diesem Patch läuft es bei mir.
Dadurch wird SQUASHFS_SWAP_LREG_INODE_HEADER nicht mehr inline aufgerufen, sondern als Funktion. Das bringt anscheinend den Compiler wieder auf den richtigen Weg. Wenn man aber den Aufruf von SQUASHFS_SWAP_LREG_INODE_HEADER komplett entfernt, funktioniert das Programm wieder nicht mehr, obwohl der Teil zur Laufzeit gar nicht aufgerufen wird.

$ cat tools/make/patches/900-gcc.squashfs3.patch
--- squashfs-tools/mksquashfs.c 2010-09-07 00:33:42.000000000 +0200
+++ squashfs-tools/mksquashfs.c 2010-09-07 00:37:09.000000000 +0200
@@ -1082,6 +1082,13 @@
        return i;
 }
 
+void
+squashfs_swap_lreg_inode_header(squashfs_lreg_inode_header *reg, squashfs_lreg_inode_header *inodep)
+{
+  SQUASHFS_SWAP_LREG_INODE_HEADER(reg, inodep);
+}
+#undef SQUASHFS_SWAP_LREG_INODE_HEADER
+#define SQUASHFS_SWAP_LREG_INODE_HEADER(reg, inodep) squashfs_swap_lreg_inode_header(reg, inodep)
 
 int create_inode(squashfs_inode *i_no, struct dir_ent *dir_ent, int type, long long byte_size, long long start_block, unsigned int offset, unsigned int *block_list, struct fragment *fragment, struct directory *dir_in)
 {

 

[er13]

@Ralf: wäre es als Workaround nicht besser bestimmte Optimierungen auszuschalten statt diesen Patch (muss zugeben bin mit dem gar nicht glücklich) anzuwenden? Könntest Du bitte testen, ob -fno-inline, -fno-tree-pre bzw. beide gleichzeitig nicht Abhilfe schaffen?

Edit: eventuell auch noch -fno-tree-pta testen

Edit2: Wenn ich mir diese Liste so anschaue, so habe ich das Gefühl, dass nur gcc-4.5.0 betroffen ist, und mit gcc-4.5.1 alles wieder funktionieren würde...

 

[RalfFriedl]

Hast Du in der Liste etwas spezifisches entdeckt, oder hoffst Du einfach, daß bei der langen Liste auch dieser Fehler mit enthalten ist?

Was besser ist, ist zum einen Ansichtssache und hängt von den Prioritäten ab.
Mit den Compiler-Optionen zu experimentieren hätte den Vorteil, daß dabei nichts am Programm geändert wird.
Mit dem Patch bleibt die volle Optimierung erhalten, weil damit ein nur Code-Zweig geändert wird, der selten, wenn überhaupt, aufgerufen wird, nämlich bei Dateien, die mehrere Links haben oder größer als 1GB sind. Mehrere Links auf eine Datei setzen wir meines Wissens nicht ein, und Dateien größer als 1GB haben wir erst recht nicht.

Die Option -fno-inline sollte keinen Unterschied machen, weil es sich hier um Makros handelt und nicht um inline-Funktionen.

 

[sf3978]

..., und mit gcc-4.5.1 alles wider funktionieren würde...

schmatke hat ja mit gcc (Ubuntu/Linaro 4.5.1-5ubuntu1) 4.5.1 ein funktionierendes Freetz-Image compiliert.

 

[schmatke]

Wenn ich mir diese Liste so anschaue, so habe ich das Gefühl, dass nur gcc-4.5.0 betroffen ist, und mit gcc-4.5.1 alles wieder funktionieren würde...

openSUSE 11.3 (x86_64)
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]

openSUSE 11.4 Milestone 1 of 6 (x86_64)
gcc (SUSE Linux) 4.5.0 20100722 [gcc-4_5-branch revision 162408]

Auf meiner fritz7170 läuft z.Z. ein Image, dass mit openSUSE 11.4 erstellt wurde.

 

[RalfFriedl]

Ob 4.5.0 funktionieren würde oder nicht, wissen wir zunächst nicht, weil beides keine Release-Versionen sind.
Man könnte an SUSE einen Bug-Report schicken. Vielleicht stellen die dann einen neuen Compiler als Update bereit.

 

[schmatke]

Ob 4.5.0 funktionieren würde oder nicht, wissen wir zunächst nicht, weil beides keine Release-Versionen sind.

Wieso? Hab doch geschrieben, dass gcc-4_5-branch revision 162408 funktioniert. Das Image war bis gerade eben auf meiner Fritzbox 7170.

Gerade eben habe ich ein Image mit opensuse 11.3, gcc-4_5-branch revision 160292 und Deinem Patch gebaut und erfolgreich auf diese Box geflasht.

Großes Kino!:groesste:

 

[RalfFriedl]

Ich wollte damit sagen, daß weder "4.5.0 20100604 [gcc-4_5-branch revision 160292]" noch "4.5.0 20100722 [gcc-4_5-branch revision 162408]" die Release-Version "4.5.0" ist.

 

[er13]

Hast Du in der Liste etwas spezifisches entdeckt, oder hoffst Du einfach, daß bei der langen Liste auch dieser Fehler mit enthalten ist?

ich hatte 44806 im Verdacht, aber der svn-Revision nach sollte der Fix in SuSE-11.3 bereits enthalten sein.

Mit dem Patch bleibt die volle Optimierung erhalten, weil damit ein nur Code-Zweig geändert wird, der selten, wenn überhaupt, aufgerufen wird,

Gerade das gefällt mir an Deiner Lösung nicht. Ich persönlich würde die an einer Stelle fehlerhaften Code hervorrufende Optimierung lieber gänzlich abschalten, Performance hin oder her. Dafür muss man aber erst rausfinden, welche Optimierung es ist.

Dein Patch an sich sorgt bei mir auch nur für noch mehr Verwirrung, denn ich verstehe ihn nicht bzw. wieso er das Problem löst - der ist für mich nur ein rein zufälliger Treffer. Ich habe ein wenig getestet: bei mir wird der SQUASHFS_LREG_TYPE-Zweig gar nicht durchlaufen, auch wenn ich mit Absicht mehrere Symlinks auf eine und dieselbe Datei anlege. Wieso sollte das Miscompilen eines Code-Stücks, welches gar nicht durchlaufen wird, von irgendeiner Bedeutung sein? Es ist aus meiner Sicht so, dass Deine Code-Änderung lediglich dafür sorgt, dass irgendeine Optimierung nicht mehr angewandt werden kann und zwar nicht auf den LREG-, sondern auf irgendein anderen (benachbarten?) Teil. Mit anderen Worten, ich würde das Problem etwas mehr verstehen wollen, bevor ich entscheide, ob ich mit dem Fix leben kann.

p.s. hat jemand schon die von mir vorgeschlagenen Compiler-Flags getestet?

 

[olistudent]

~/trunk> tools/unsquashfs3-lzma build/modified/kernel/kernelsquashfs.raw
0 inodes (0 blocks) to write

Gleitkomma-Ausnahme

Dein Patch behebt das Problem für mich nicht.

MfG Oliver

edit: Mit "-fno-tree-pta" kann ich das squashfs wieder entpacken.

 

[RalfFriedl]

ich hatte 44806 im Verdacht

Bei dem steht "This bug manifests on i686, and not on x86_64." Bei mir tritt der Fehler beim x86_64 auf.

Gerade das gefällt mir an Deiner Lösung nicht...

Mir gefällt der Patch auch nicht. Und Lösung würde ich ihn erst recht nicht nennen, außer, daß ein funktionsfähiges Programm herauskommt.
Wenn man die Optimierung ausschaltet, würde man das konsequenterweise für alle Programme tun, die auf dem Host erstellt werden.

Dein Patch an sich sorgt bei mir auch nur für noch mehr Verwirrung, denn ich verstehe ihn nicht bzw. wieso er das Problem löst

Von der Funktionsweise ist der Patch einfach:
Es gibt ein vorhandenes Makro SQUASHFS_SWAP_LREG_INODE_HEADER, das auf eine Unmenge von Anweisungen expandiert wird. Es wird eine Funktion definiert, die genau dieses Makro aufruft. Das Makro wird danach so umdefiniert, daß es diese Funktion aufruft. Funktional ist der Code identisch, aber bei der Optimierung von create_inode macht es einen Unterschied.
Zuerst hatte ich vor, diese Umdefinition für alle Fälle zu machen, aber nachdem es schon mit diesem einen ging, hatte ich nicht weiter gemacht.

Wenn es Dich beruhigt, ich weiß auch nicht, warum es mit diesem Patch funktioniert. Wie bereits oben geschrieben, funktioniert das Programm nicht, wenn man den Aufruf von SQUASHFS_SWAP_LREG_INODE_HEADER komplett entfernt. Es hilft auch nicht, den kompletten LREG-Zweig zu entfernen.

Man könnte ausprobieren, welche Zweige bei unseren konkreten Firmwares tatsächlich gebraucht werden und ob es funktioniert, wenn man alle anderen entfernt.

bei mir wird der SQUASHFS_LREG_TYPE-Zweig gar nicht durchlaufen, auch wenn ich mit Absicht mehrere Symlinks auf eine und dieselbe Datei anlege.

Ich hatte bereits geschrieben, daß der Zweig bei uns höchstwahrscheinlich gar nicht genutzt wird. Ein Symlink ist etwas anderes als ein (Hard-)Link. Den kannst Du mit "ln" ohne die Option "-s" anlegen. Ich bin zuversichtlich, daß das Programm damit auch korrekt läuft, aber wie Du selbst festgestellt hast, ist dieser Fall für unsere Firmwares nicht von Bedeutung.

Wieso sollte das Miscompilen eines Code-Stücks, welches gar nicht durchlaufen wird, von irgendeiner Bedeutung sein? Es ist aus meiner Sicht so, dass Deine Code-Änderung lediglich dafür sorgt, dass irgendeine Optimierung nicht mehr angewandt werden kann und zwar nicht auf den LREG-, sondern auf irgendein anderen (benachbarten?) Teil.

Zunächst ist es ein Problem des Compilers, und der Compiler kann nicht wissen, welche Teile des Programms später tatsächlich ausgeführt werden und welche nicht. Es könnte ja sein, daß Dateien mit mehreren Links oder mehr als 1GB vorkommen, wobei der Compiler auch nicht wissen kann, welche externen Bedingungen dafür sorgen würden, daß dieser Teil des Codes ausgeführt wird.
Der Compiler versucht nicht nur, einzelne Code-Zweige zu optimieren, sondern die Funktion als ganze. Irgendwo kommt er dabei durcheinander. Vielleicht, weil diese SWAP-Macros einiges an gemeinsamem Code enthalten, das des Compiler als identisch erkennt, und dies nach der Änderung nicht mehr der Fall ist.

Mit anderen Worten, ich würde das Problem etwas mehr verstehen wollen, bevor ich entscheide, ob ich mit dem Fix leben kann.

Wie schon geschrieben, gefällt mir der Fix auch nicht. Ich würde ihn eher hier im Thread stehen lassen für diejenigen,die diesen Compiler nutzen, als ihn mit aufzunehmen.

Dein Patch behebt das Problem für mich nicht.

Welcher Patch? Der Patch von mir ändert mksquashfs3-lzma, nicht unsquashfs3-lzma

 

[olistudent]

Die Antwort war für er13. Dein Patch funktioniert auch, Ralf.

MfG Oliver

edit: Mit Ubuntu Lucid "gcc version 4.5.1 20100419 (prerelease) (Ubuntu 4.5.0-2ubuntu1~ppa2)" funktioniert es auch ohne Patches.

 

[olistudent]

Wie gehts denn hier weiter?

MfG Oliver