Thema: Kernel mit GCJ

[Vogtinator]

Öhm, was? CVS braucht für jede einzelne Aktion Netzwerkzugriff, das ist lahm und behindert mich beim Arbeiten. Was den ersten Checkout angeht, hat MNemo über die Datenmenge ja schon was gesagt, aber ehrlichgesagt kommt mir da in den meisten Fällen git trotzdem sogar schneller vor.

Ist ja auch völlig egal was schneller ist, solange es funktioniert und man alte Versionen zurückspielen kann, ist alles in Ordnung.

Ich schätze, es ist kein besonders verbreitetes Hobby, Java-Standardbibliotheken zu schreiben...

Zum Glück, sonst gäb es ja tausende SDKs für jede noch so unwichtige Sache..

Die Warnung kommt in deinem ursprünglichen Code mit dem manuell gemangelten Namen nicht (weil der Compiler dann halt nicht blickt, was du vorhast), aber wenn du Init::write_char schreiben willst, dann brauchst du auch das extern "Java" und dann kommt die Meldung.

Code: [Auswählen]

$ gcj --version
gcj (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
Die Definition habe ich so in gcj/javaprims.h gefunden. Wenn __java_char bei dir nicht tut, kannst du ja mal schauen, was da bei dir steht.

Den Header habe ich jetzt einfach mal inkludiert (er verweist zum Glück nicht auf andere Header ).
Da steht nämlich so in etwa:

Code: [Auswählen]

extern "Java" {
typedef __java_char jchar;
}
An dem "extern 'Java'" (ich kann es jetzt schon nicht mehr hören  ) scheint es wohl gelegen zu haben.
Auf jeden Fall sieht der Code jetzt schon mal viel schöner aus, so komplett ohne manuelles Mangling 
Dann kommt wohl als nächster Schritt, Umwandlungsfunktionen zu basteln.
Einfach nur casten ist zu unsauber (aber funktioniert  )

[kevin]

Da steht nämlich so in etwa:

Code: [Auswählen]

extern "Java" {
typedef __java_char jchar;
}
An dem "extern 'Java'" (ich kann es jetzt schon nicht mehr hören  ) scheint es wohl gelegen zu haben.

Das stand aber ziemlich genau exakt so auch in meinem Patch. Hast du dir nur einzelne Zeilen rausgepickt?

[Vogtinator]

Das stand aber ziemlich genau exakt so auch in meinem Patch. Hast du dir nur einzelne Zeilen rausgepickt?

Stimmt 
Da war ich entweder zu blind oder zu blöd 

[Vogtinator]

Ich bin jetzt schon einmal weiter gekommen, Init.java kann ich schon instanzieren und eine private Methode aufrufen.

Allerdings habe ich jetzt das Problem, dass z.B.

Code: [Auswählen]

Console screen;nicht funktioniert. Der Konstruktor wird wahrscheinlich nicht aufgerufen.

Code: [Auswählen]

Console* screen;

void foo() { screen = new Console(); }funktioniert aber einwandfrei.

Mit ld --print-map und zahlreichen nm foo.o Aufrufen habe ich rausgefunden, dass es keine Section .ctors oder .dtors gibt!
Stattdessen erscheint immer, wenn ich eine solche benötige, eine Funktion "_Z41__static_initialization_and_destruction_0ii" bzw. "__static_initialization_and_destruction_0(int, int)".
Anscheinend wird diese nicht richtig gelinkt oder sonst irgendetwas anderes, das ich mir nicht erklären kann.
Sowohl mein eigenes Linkerscript als auch das von http://www.lowlevel.eu/wiki/C%2B%2B-Kernel_mit_GRUB funktionieren nicht.
Hat jemand eine Ahnung, woran das liegen könnte?
Version von ld ist: 2.22 (openSUSE 12.2).
GCC: 4.7.1 (ebenfalls openSUSE 12.2)

[kevin]

Wart mal, versuchst du hier, eine Java-Klasse aus C++-Code heraus auf dem Stack zu instanzieren? Das klingt leicht kriminell...

Ansonsten, irgendwo muss diese __static_initialization_and_destruction_0() ja referenziert werden?

[rizor]

Falls du dir nicht sicher bist, ob die Funktionen referenziert werden, lass gjc und ld mal Testweise mit -flto laufen.
Wenn du in der Binary das Dingen dann noch immer findest, übersiehst du nur die Referenz

[MNemo]

Wart mal, versuchst du hier, eine Java-Klasse aus C++-Code heraus auf dem Stack zu instanzieren? Das klingt leicht kriminell...

Die Symptome deuten eher nicht darauf hin. Es geht wohl eher um eine globale Instanze.

Evtl. hilft die ja der zweite treffer von Google weiter: g++ __static_initialization_and_destruction_0(int, int) - what is it

[kevin]

Ja, gut, von mir aus auch globale Instanzen. Das haben normale Java-Klassen aber genausowenig.

[Vogtinator]

Wart mal, versuchst du hier, eine Java-Klasse aus C++-Code heraus auf dem Stack zu instanzieren? Das klingt leicht kriminell...

Nein, eine ganz normale C++ Klasse.
Zur dunklen Seite bin ich nicht übergetreten, auch wenn es garantiert ohne weiteres möglich ist, aus C++ heraus ein Java-Objekt zu instanzieren (frag mich nur nicht wie, ich werds bald herausfinden).

Falls du dir nicht sicher bist, ob die Funktionen referenziert werden, lass gjc und ld mal Testweise mit -flto laufen.
Wenn du in der Binary das Dingen dann noch immer findest, übersiehst du nur die Referenz

Danke für den Tipp, das Symbol ist immer noch drin 
Aber es werden mit einem "objump -D main.o | grep Z41 -B10" nur die Funktion selbst und eine andere, die "_GLOBAL__sub_I_screen" (die vermutlich den Konstruktor von Console für "Console screen" aufruft), ausgegeben 
Die funktionen referenzieren sich also nur gegenseitig, also muss eine davon manuell aufgerufen werden.
Ich habe aber keine Ahnung, warum die beiden dann beim Linken nicht rausgekürzt werden.
"start_ctors" und "end_ctors" haben auch immer die exakt gleiche Adresse im kernel.
Außer einer neuen Funktion, "__gnu_lto_v1" bewirkt der Parameter "-flto" irgendwie nix.

Evtl. hilft die ja der zweite treffer von Google weiter: g++ __static_initialization_and_destruction_0(int, int) - what is it

Dadrin ist mir sofort das folgene ins Auge gesprungen:

g++ does have a -fno-use-cxa-atexit command line option but I don't think that'll help. It looks like it just causes atexit() to be used instead of cxa_atexit(). Perhaps the better question to ask is why g++ generates __static_initialization_and_destruction_0() to begin with instead of placing constructor and destructor calls in the .ctors and .dtors ELF sections. Presumably there's a good reason for it.

Auf Deutsch: Anscheinend bringt -fno-use-cxa-atexit nix mehr, denn g++ hat aus einem wahrscheinlich "guten Grund" darauf verzichtet, die Sections .ctors und .dtors zu verwenden. 
Was jetzt?
Ich denke ich muss die __static_initialization_and_destruction_0(int, int) Manuell aufrufen, aber
1. Mit welchen Parametern?
2. Das Symbol heißt dann doch in jeder Objekt-Datei mit statischen/globalen C++-Variablen gleich, das gibt doch Kollisionen!

Das einzige (halbwegs brauchbare) im Netz was ich sonst noch so gefunden habe, ist http://gcc.gnu.org/ml/gcc/2003-11/msg01211.html,
aber in dem Thread gehts nur um eine fehlende Funktion.
Ich bin mit meinem Latein am Ende..
Soll ich es mal mit einer älteren gcc-Version ausprobieren?
Ich hab noch die 4.5.1 (opensuse 11.4) auf meinem Server.

[MNemo]

g++ does have a -fno-use-cxa-atexit command line option but I don't think that'll help. It looks like it just causes atexit() to be used instead of cxa_atexit(). Perhaps the better question to ask is why g++ generates __static_initialization_and_destruction_0() to begin with instead of placing constructor and destructor calls in the .ctors and .dtors ELF sections. Presumably there's a good reason for it.

Auf Deutsch: Anscheinend bringt -fno-use-cxa-atexit nix mehr, denn g++ hat aus einem wahrscheinlich "guten Grund" darauf verzichtet, die Sections .ctors und .dtors zu verwenden. 

Stimmt, da war was. Aber ich bekomme bei mir jetzt .init_array und .fini_array sections. Und keine__static_initialization_and_destruction_0(int, int).

Ich nutze g++ 4.7, mit etwa "-c -O3 -flto -funsigned-bitfields -fno-stack-protector -fno-builtin -std=c++0x -fno-exceptions"

[Vogtinator]

Ich nutze g++ 4.7, mit etwa "-c -O3 -flto -funsigned-bitfields -fno-stack-protector -fno-builtin -std=c++0x -fno-exceptions"

Endlich gehts..
Ich weiß zwar nicht, woran das lag, aber mit deinen Parametern funktionierts endlich und ich habe eine Section .init_array, in der die static_iniirgendwas aufgerufen wird!
Hab ich einfach im Linkerscript eingesetzt und - es geht!
DANKE, DANKE, DANKE! 

[DesL]

Wenn dir der Constructor eines globalen C++-Objects nicht aufgerufen wird, iterierst du vermutlich nicht durch die Constructor Liste zu begin... siehe: http://www.lowlevel.eu/wiki/C%2B%2B#globale.2Fstatische_Objekte

Kannst du den Quellcode auch mal woanders hochladen? Die RWTH-Firewall sperrt dyndns.biz oder was du da hast....

[Vogtinator]

Ja, hier, auf Dropbox:
http://dl.dropbox.com/u/105478372/gcj-kernel.zip

Wenn dir der Constructor eines globalen C++-Objects nicht aufgerufen wird, iterierst du vermutlich nicht durch die Constructor Liste zu begin... siehe: http://www.lowlevel.eu/wiki/C%2B%2B#globale.2Fstatische_Objekte

Doch, tu ich.
Funktioniert ja.

Die RWTH-Firewall sperrt dyndns.biz oder was du da hast....

Kenne ich irgendwoher, unsere Firewall in der Schule hatte auch dyndns gesperrt, sogar die IPs (entweder Cache oder reverse DNS).
Aber jetzt ist das anders, jetzt darf ich das Netzwerk dort (mit-) verwalten

[Vogtinator]

Strings funktionieren auch schon, kann aber noch ein bisschen dauern, bis man die auch benutzen kann.
Die ganzen Funktionen müssen ja ersteinmal implementiert werden.