Dbox2-Images mit gcc 4.x

[rhabarber1848]

Hi,

wie bereits erwähnt, arbeite ich gerade an einem Patch, der es erlaubt,
Dbox2-Images mit gcc 4.1.2 zu bauen, aktuell nur mit Kernel 2.4.
Ein solches Images setze ich bereits seit einigen Wochen ein, wobei
ich noch keine abschließenden Angaben zur Stabilität machen kann.

Allerdings stürzt sectionsd scheinbar nicht mehr ab, seit Gaucho316 eine
weitere Version des Patches veröffentlicht hat.

Ich werde den Patch noch nicht veröffentlichen, da ich ihn noch in
Einzelteile aufsplitten werde, die ich mit gcc 3.4.6 testen werde.

Geplant ist zudem eine (weitere ) cdk/configure-Option --with-gcc,
die eine Auswahl des Compilers für Dbox2-Image erlaubt.

Erstellt habe ich das Posting heute, um schon einmal die Größenunterschiede
der Images zu dokumentieren:

root-neutrino.squashfs mit gcc 4.1.2: 4878336 Byte
root-neutrino.squashfs mit gcc 3.4.6: 5087232 Byte

root-neutrino.squashfs_nolzma mit gcc 4.1.2: 5939200 Byte
root-neutrino.squashfs_nolzma mit gcc 3.4.6: 6205440 Byte

[rhabarber1848]

Ich nutze gcc 4.1.2, weil Kernel 2.4 nicht mit gcc >= 4.2* kompilierbar ist:
http://www.tuxbox-cvs.sourceforge.net/f ... 15#p379415

Haltet ihr es für sinnvoll, nur den Dbox2-Kernel 2.4 mit gcc 4.1.2 zu kompilieren
und für den Rest eine neuere Version zu wählen? Und falls ja, welche?
glibc-2.3.6 muss auch noch mitspielen...

(Und ja, für mich ist es sinnvoll, Zeit in ein Dbox2-Image zu investieren, da ich
mir derzeit keine andere Box zulegen will. )

[seife]

Warum willst du keine Aktuellere glibc verwenden?

[rhabarber1848]

Afaik kann Vanilla-Kernel 2.4 kein NPTL und neuere glibc-Versionen
können kein linuxthreads.

PS: Zumindest dachte ich das immer, es scheint wohl nicht zu stimmen:
http://ltsp.mirrors.tds.net/pub/sourcew ... snapshots/
Dort findet sich z.B. glibc-2.9-linuxthreads-20090518.tar.bz2 ...

Scheinbar gibt es linuxthreads auch für eglibc:
http://ftp.cross-lfs.org/pub/clfs/congl ... uxthreads/

Wobei nicht klar scheint, ob das aktuell noch unterstützt wird:
http://www.eglibc.org/archives/issues/msg00080.html

Auf die richtige Mischung kommt es an
Für entsprechende Tipps bin ich jederzeit dankbar!

[seife]

Erfahrung habe ich da auch keine. Das letzte Projekt das ich mit 2.4 gesehen habe hat uclibc benutzt.

Es wird halt mit neueren Compilern schwieriger, die alte glibc zu kompilieren, weil die neuen Compiler pingeliger sind und teilweise den alten glibc-Code anmeckern. Deswegen hatte ich gefragt.
Für die TD habe ich ja auch alten Compiler / alte glibc oder halt neuer Compiler / neue glibc in den Makefiles zur Auswahl gestellt. Alles andere war einfach zu anstrengend
Und alter Compiler / alte glibc fliegt bald raus, weil sich das alte crosstool immer schlechter mit neuen Compilern kompilieren lässt... Bei mir ist allerdings die Grösse des dabei rauskommenden Codes nicht so wichtig. Es kann nämlich gut sein, dass eine neuere glibc wesentlich grösser wird...

[rhabarber1848]

Es wird halt mit neueren Compilern schwieriger, die alte glibc zu kompilieren, weil die neuen Compiler pingeliger sind und teilweise den alten glibc-Code anmeckern.

Für gcc 4.1.2 & glibc 2.3.6 hält sich der Patchaufwand noch in Grenzen. Ich werde
es erstmal dabei belassen, da es hier schon funktioniert, mit 58kb ist der Patch
schon gross genug

[rhabarber1848]

commoncpp2-1.0.13.tar.gz kompiliert nicht mit gcc 4.1.2.
Lt. cdk/make/* benötigt nur lcars diese lib, allerdings vermisst lcars diese lib
nicht, lcars kompiliert auch ohne. Ich werde sie daher in meinem Patch entfernen,
irgendwelche Einwände?

PS: Erledigt: http://article.gmane.org/gmane.comp.vid ... x.scm/2837

[seife]

Hau weg. Bzw. kannst du die Targets ja da lassen, aber halt nicht bauen, dann kann das später jemand leichter fixen.

Ich habe beim neutrino-HD Buildsystem ein "make/unmaintained.mk" für sowas

sigc++ ist auch so ein Ding, was nur von einem einzigen Enigma-plugin benötigt wird IIRC, aber (zumindest früher) immer gebaut wurde und gern ein wenig "schwierig" war.

[rhabarber1848]

Hi,

hier sind die Patches, die Kompilierprobleme mit gcc 4.1.2 beheben,
gcc 4.1.2-Support selbst ist noch nicht enthalten. Es geht erstmal darum, ob
meine Patches noch mit gcc 3.4.6 funktionieren bzw. ob meine Patches überhaupt
in Ordnung sind, da ich kein C/C++-Experte bin.

Patch für gcc4-Anpassungen in apps/ (zapit, neutrino, lcars, radiobox, ...):
EDIT: Patch ist im CVS

Während der Arbeiten am gcc4-Support habe ich herausgefunden, dass die Kernel-
Module gestript werden können, der dafür notwendige Patch für driver/ ist auch
für den gcc4-Support notwendig: EDIT: Patch ist im CVS
Mit diesem Patch werden die Kernel-Module nicht gestript, das ist so beabsichtigt.

Patch für restliche gcc4-Anpassungen in driver/: EDIT: Patch ist im CVS

Bitte testet alle o.g. Patches zusammen im aktuellen Tuxbox CVS und berichtet,
ob es Probleme gibt.

[GetAway]

Hi,

alle 3 Patche eingespielt. Kompiliert ohne sichtbare Probleme, habe es jetzt nicht mitgeloggt.
Yadd bootet, TV läuft.

[poeschel]

Ich hab grade mal testweise mit gcc 4.4.3 compiliert. Ein paar Sachen, die mir aufgefallen sind:
Warum kommen in eventwatchdog.h und basicclient.h leere Destruktoren dazu ? (gcc 4.4.3 braucht die nicht. 4.1.2 etwa ?)

Leider konnte ich auf einfache Weise das compilen in driver nicht testen, aber in driver/dvb/driver/media/dvb/avia stimmt irgendwas nicht. Dieses wilde hin- und hergecaste wirkt komisch. Da wird z.B. avia_gt_dmx.[c|h] aus

Code: Alles auswählen

const u8 *

ein

Code: Alles auswählen

const char*

um dann dieselbe Variable in avia_gt_napi.c von

Code: Alles auswählen

const u8 *

wieder nach

Code: Alles auswählen

const char*

zu casten. Dabei hab ich ein schlechtes Gefühl, wie gesagt ich konnte es leider auf die Schnelle nicht testen. Das ist aber total unkonsequent. Der Code, den der Compiler produziert, wird an dieser Stelle funktionieren, weil auf powerpc sizeof(char)==sizeof(unsigned char)==sizeof(u8) ist, aber sauber ist das nicht.
In avia_gt_v4l2.c würde ich wahrscheinlich

Code: Alles auswählen

strcpy

durch

Code: Alles auswählen

memcpy

ersetzen.
Kann man in saa7126_core.h das

Code: Alles auswählen

__attribute__((packed))

hinter

Code: Alles auswählen

s_saa_data

schreiben ?
Ansonsten gute Arbeit!

Grüße!

[GetAway]

Wenn du einen Patch machst, wird's bestimmt jemand testen.
An die Treiber traut sich eh keiner mehr ran. Vielleicht du?

[seife]

Die Treiber können zumindest für kernel 2.4 sowenig mit gcc > 4.1 kompiliert werden wie der Kernel.

u8 ist dasselbe wie unsigned char, und powerpc hat char == unsigned char.

wenn man die struct nicht packed, dann passt sie nicht mehr zur Hardware.

Die Treiber sind schon in Ordnung so.

[rhabarber1848]

Warum kommen in eventwatchdog.h und basicclient.h leere Destruktoren dazu ? (gcc 4.4.3 braucht die nicht. 4.1.2 etwa ?)

http://cvs.tuxbox-cvs.sourceforge.net/c ... iew=markup

CFLAGS="-Wall $(TARGET_CFLAGS)" \
CXXFLAGS="-Wall $(TARGET_CXXFLAGS)" \

libtool: compile: powerpc-tuxbox-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../include -I/root/tuxbox/work_glibc/image/cdkroot/include/tuxbox -I/root/tuxbox/work_glibc/compile/driver/include -I/root/tuxbox/work_glibc/compile/driver/dvb/include -I/root/tuxbox/work_glibc/image/cdkroot/include/tuxbox -Werror -Wall -pipe -Os -fno-rtti -fno-exceptions -MT zapitclient.lo -MD -MP -MF .deps/zapitclient.Tpo -c zapitclient.cpp -fPIC -DPIC -o .libs/zapitclient.o
cc1plus: warnings being treated as errors
/root/tuxbox/work_glibc/image/cdkroot/include/tuxbox/connection/basicclient.h:33: warning: 'class CBasicClient' has virtual functions but non-virtual destructor
../include/zapit/client/zapitclient.h:34: warning: 'class CZapitClient' has virtual functions but non-virtual destructor

[rhabarber1848]

wenn man die struct nicht packed, dann passt sie nicht mehr zur Hardware.

Die Treiber sind schon in Ordnung so.

Ich verstehe leider nicht, was Du damit meinst. Bezieht sich die Aussage auf das
posting von poeschel oder meinen Patch für driver/include/dbox/saa7126_core.h?
Darin habe ich massenhaft

Code: Alles auswählen

__attribute__((packed))

entfernt, um das hier zu beheben:

cc1: warnings being treated as errors
In file included from saa7126_core.c:36:
../include/dbox/saa7126_core.h:76: warning: 'packed' attribute ignored for field of type 'unsigned char'

[rhabarber1848]

Kann man in saa7126_core.h das

Code: Alles auswählen

__attribute__((packed))

hinter

Code: Alles auswählen

s_saa_data

schreiben ?

Dieser Patch, zusätzlich zu meinem Patch:

Code: Alles auswählen

--- saa7126_core.h	2011-05-18 18:28:41.000000000 +0200
+++ saa7126_core.h.patched	2011-05-18 18:57:09.000000000 +0200
@@ -255,7 +255,7 @@
 	unsigned char ttxl15    : 1;
 	unsigned char ttxl14    : 1;
 	unsigned char ttxl13    : 1;
-} s_saa_data;
+} s_saa_data __attribute__((packed));
 
 #define SAA_DATA_SIZE		sizeof(s_saa_data)
 

kompiliert. Ist er notwendig?

[seife]

Das war eine Antwort auf poeschel.

Ohne den code genau anzuschauen kann ich das nicht genau sagen. Wenn die ganze struct wirklich nur ein char ist, dann ist das __attribute__((packed)) nicht notwendig. Wenn nicht, dann muss sie gepackt werden, weil sonst zwischen den elementen "Füllbytes" sein können die den direkten Hardwarezugriff (wenn z.B. memory-mapped I/O gemacht wird) empfindlich stören können.

Wie die syntax genau ist, ob das also dahinter oder davor geschrieben werden kann/muss weiss ich jetzt auch nicht auswendig.

Wenn der Treiber funktioniert, kann es so falsch nicht sein ;-)

[Houdini]

ich glaube die Bitfelder müssen immer unsigned int sein:
also

Code: Alles auswählen

   unsigned int ttxl15    : 1;
   unsigned int ttxl14    : 1;

dann sollte packed auch wieder passen

[poeschel]

http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
Meiner Meinung nach ist das

Code: Alles auswählen

__attribute__((packed))

in der struct hinter jedem bitfield vollkommen Blödsinn, weil es dort ja nichts zu packen gibt. Wenn, dann will man die ganze struct packen, deswegen dahinter.
Was das packed bewirkt, ist, dass die einzelnen Member des struct direkt hintereinander im Speicher angelegt werden. Wenn man das packed weglässt, kann der Compiler selbst entscheiden, wie er die einzelnen Member im Speicher anordnet und ob er evtl Leerstellen einfügt (optimiert), damit er dann einen schnelleren Zugriff darauf hat, wenn er das gewünschte Member dann an einer geraden (oder durch 4 teilbaren) Adresse angeordnet hat.
Die Optimierungen sind in einer struct, mit der man Hardwareregister ansprechen möchte, natürlich nicht gewünscht, weil man ja sonst das entsprechende Register eventuell nicht "trifft".
Nun hat der Compiler bei Bitfields (und die struct enthält ja aussschließlich Bitfields) wahrscheinlich wenig "Optimiertungsspielraum", weil er bei einem Zugriff eh hin und her shiften, bzw Bits ausblenden muss, so dass die struct auch funktioniert, wenn das packed nicht dran steht. Ich würde es trotzdem dahinter schreiben,um damit ausdrücklich zu signalisieren, dass hier keine Optimierung erwünscht ist.
Zum Thema, welchen Typ man in dem Bitfield verwendent (unsigned char oder unsigned int), das ist relativ Wurst, Hauptsache, die gewünschte Anzahl von Bits passen rein, deshalb ist der "empfohlene" Typ das unsigned int, dort ist man einfach sicherer, es passen im Zweifel mehr bits rein. In unserem Fall kann aber das char stehen bleiben.
Das mit den leeren Destruktoren geht natürlich auch vollkommen in Ordnung. Ich wusste nicht, dass man den jetzt braucht, wenn man ne virtuelle Methode hat.

[poeschel]

Mir fällt grade noch ein Fehler von mir auf. Im oben verlinkten Manual steht dieses:

You may only specify this attribute on the definition of an enum, struct or union, not on a typedef which does not also define the enumerated type, structure or union.

Deswegen ist es in unserem Fall, wenn typedef und struct in einem verwendet wird egal, ob davor oder dahinter. (So versteh ich zumindest die Aussage )

Wenn man nur das struct hätte, MÜSSTE es davor.
So:

Code: Alles auswählen

struct __attribute__ ((__packed__)) s_saa_data {

Übrigens wird das im Manual immer so verwendet:

Code: Alles auswählen

__attribute__ ((__packed__))

Also mit Unterstrichen am packed. Ich weiss nicht, ob die notwendig sind.

[rhabarber1848]

Das mit den leeren Destruktoren geht natürlich auch vollkommen in Ordnung. Ich wusste nicht, dass man den jetzt braucht, wenn man ne virtuelle Methode hat.

gcc412_apps.diff habe ich soeben committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/2838
http://article.gmane.org/gmane.comp.vid ... x.scm/2839
http://article.gmane.org/gmane.comp.vid ... x.scm/2840
http://article.gmane.org/gmane.comp.vid ... x.scm/2841
http://article.gmane.org/gmane.comp.vid ... x.scm/2842
http://article.gmane.org/gmane.comp.vid ... x.scm/2843
http://article.gmane.org/gmane.comp.vid ... x.scm/2844

Über driver/ sollten wir wohl noch ein wenig diskutieren
Wie schaut es mit dem Kernel-Module-strip-Patch aus?
Hat den außer GetAway noch jemand getestet?

[poeschel]

Über driver/ sollten wir wohl noch ein wenig diskutieren

Ich hab mir mal die Mühe gemacht und nen entsprechenden CrossCompiler gebaut und mich auch an dem driver versucht, wen es interessiert, patch hängt an. Prinzipiell bin ich auf nahezu das gleiche Ergebnis gekommen, wie rhabarber1848, nur in avia ist es mir glaub ich gelungen, ein paar weniger casts zu verwenden. Das Problem ist tatsächlich, dass im Kernel in den verschiedenen Teilen unterschiedliche Typen für Puffer verwendet werden. (i2c vs. dvb Teil und char vs u8) Daher lassen sich an bestimmten Stellen die casts nicht vermeiden. Welchen patch du commitest, macht glaub ich wirklich nicht viel Unterschied.

[dbluelle]

Nur so am Rande:
Bei den am Donnerstag eingecheckten Sachen fehlt anscheinend die Datei Patches/linux-2.4-cifs_gcc4.diff.

[rhabarber1848]

Bei den am Donnerstag eingecheckten Sachen fehlt anscheinend die Datei Patches/linux-2.4-cifs_gcc4.diff.

http://article.gmane.org/gmane.comp.vid ... x.scm/2850

[rhabarber1848]

Prinzipiell bin ich auf nahezu das gleiche Ergebnis gekommen, wie rhabarber1848, nur in avia ist es mir glaub ich gelungen, ein paar weniger casts zu verwenden.

Ich habe Deine Version soeben ins CVS committed, danke!