MONO crosscompile mit Freetz

[RalfFriedl]

Tatsache die Parameterübergabe verdreht es. Oder seh ich das falsch?

  88:	8fa50014 	lw	a1,20(sp)
  8c:	8fa40010 	lw	a0,16(sp)

   8:	afa40034 	sw	a0,52(sp)
   c:	afa50030 	sw	a1,48(sp)

Ja, sieht ganz danach aus. a0 wird aus dem unteren Wort geladen, aber auf das obere Wort gespeichert. Du müsstest jetzt nur noch herausfinden, woher das kommt. Wie sieht es mit einer einfachen Zuweisung aus, passiert da das gleiche? Also "long a, b = 1; a = b;". Oder ist es nur der Code, der die Parameter aus den Registern auf den Stack bringt? Wie sieht denn der Zwischencode dazu aus?

 

[neolithos]

@RalfFriedl:
Schau mal das Post #80 an.

Der Code ist die Korrektur.

Nachtrag I:
In Zeile 1728 ist der Gegenpart, dort werden die Daten übergeben.

Nachtrag II:
Kann sein das ich bei der Zeile 5205 falsch liege. Müsste man mal ausprobiert

 

[RalfFriedl]

In [POST=2008023]Post #80[/POST] sehen die zwei Stellen Zeile 5167 und Zeile 5205 so aus, als würden sie zueinander passen, also reg+0 verwendet in beiden Fällen ms_word_offset und reg+1 in beiden Fällen ls_word_offset.

Im Prinzip ist es fast egal, wie die Parameter übergeben werden, solange die aufrufende Funktion und die aufgerufene Funktion sich darüber einig sind.
Sofern man aber auch andere Funktionen aufrufen will, beispielsweise aus der C Library, muss man sich an deren Konventionen halten. Ich vermute, dafür sind die Zeilen "if _MIPS_SIM == _ABIO32" usw., aber ich weiß nicht, welche davon für die Box verwendet wird. Und da sieht es so aus:
MIPSEL:
a0: Low-Word
a1: High-Word

MIPS:
a0: High-Word
a1: Low-Word

Der Teil, der an der niedrigeren Speicheradresse abgelegt wird, kommt auch in das Register mit der kleineren Nummer. Anscheinend wird das hier nicht berücksichtigt. Ich würde den obigen Abschnitt aber so deuten, dass in das untere Register immer das High-Word (aus ms_word_offset) kommt, und das wäre für MIPS richtig. Und die 7390, die im ersten Beitrag erwähnt wird, hat MIPS. Hast Du auch eine Box mit MIPS, oder eine mit MIPSEL?

 

[neolithos]

Die Ausschnitte im Post 80 sind die Funktionspreampel, also der Parameterkonsument. In Post 82 ist die Zeilennummer für das zusammenbauen des calls. Die beiden passen meiner Meinung nach nicht zu zusammen. Bei der Zeile 5205 werde ich noch prüfen, ob die bei mir überhaupt Verwendung finden. Danach muss man noch ne Stackübergabe erzwingen, und prüfen ob das hinhaut. Zur Zeit analysieren ich den Abschnitt noch, der mit der größte im Mipscode ist. Ich hoffe das ich dabei die richtige Reihenfolge ermitteln.

Einen mipsel habe ich leider nicht, nur ne 7490 und die arbeitet EB.

Zur Zeit mach ich eigentlich nur ein Codereview von einem ziemlich großen Projekt.

 

[RalfFriedl]

Der Aufruf oben ist korrekt, das Wort von der niedrigen Adresse kommt ins Register mit der niedrigen Nummer:

  88:	8fa50014 	lw	a1,20(sp)
  8c:	8fa40010 	lw	a0,16(sp)

Das Problem ist in der Funktion, die aufgerufen wird. Ich bin aber nicht sicher, ob es die Parameter Annahme selbst ist. In [POST=2008011]#79[/POST] hast Du diese Funktion:

		private static unsafe void  WriteLong2(long v)
		{
			int* a = (int*)(void*)&v;
			int ms = *a;
			int ls = *(a + 1);
			WriteInt (ms);
			WriteInt (ls);
		}

Die Konstruktion erzwingt, dass ein Parameter, der im Register übergeben wird, in den Speicher geschrieben wird, damit man die Adresse einem Pointer zuweisen kann. Teste mal folgende Alternative:

		private static unsafe void  WriteLong2(long v)
		{
			int ms = (v >> 32) & 0xFFFFFFFF;
			int ls = v & 0xFFFFFFFF;
			WriteInt (ms);
			WriteInt (ls);
		}

Kommen da die richtigen Werte heraus? Wie sieht der MIPS Code dazu aus?

Hast Du in [POST=2008023]#80[/POST] bereits ls_word_offset und ms_word_offset vertauscht? Wenn ja, hat es geholfen? In https://github.com/corngood/mono/blob/master/mono/mini/mini-mips.c#L5163 steht es nämlich anderes herum. Die zweite Stelle bezieht sich auf Float Werte (ArgInFRe) und nicht Integer (ArgInIReg), aber natürlich sollten die auch richtig funktionieren.

 

[neolithos]

Hast Du in [POST=2008023]#80[/POST] bereits ls_word_offset und ms_word_offset vertauscht? Wenn ja, hat es geholfen? In https://github.com/corngood/mono/blob/master/mono/mini/mini-mips.c#L5163 steht es nämlich anderes herum. Die zweite Stelle bezieht sich auf Float Werte (ArgInFRe) und nicht Integer (ArgInIReg), aber natürlich sollten die auch richtig funktionieren.

Ja, sind vertauscht. Weil es nicht mit dem Call übereinstimmt. Ich suche derzeit nur noch die Stellen für die Übergabe der Doublewerte und der Stackwerte.

Auch dein Bsp klappt sauber, da die Operationen sauber implementiert sind, und der Code zwischen verschiedenen Platformen getauscht und getestet wird (ist ja nicht in der mini-mips.c).

00000000 <tMono_MainClass_WriteLong3>:
   0:	27bdffe0 	addiu	sp,sp,-32
   4:	afbf001c 	sw	ra,28(sp)
   8:	afa40020 	sw	a0,32(sp)
   c:	afa50024 	sw	a1,36(sp)
  10:	8fa50024 	lw	a1,36(sp)
  14:	8fa40020 	lw	a0,32(sp)
  18:	24060020 	li	a2,32
  1c:	3c190056 	lui	t9,0x56
  20:	27396730 	addiu	t9,t9,26416
  24:	0320f809 	jalr	t9
  28:	00200825 	move	at,at
  2c:	afa20010 	sw	v0,16(sp)
  30:	afa30014 	sw	v1,20(sp)
  34:	00602021 	move	a0,v1
  38:	3c192ab2 	lui	t9,0x2ab2
  3c:	2739c410 	addiu	t9,t9,-15344
  40:	0320f809 	jalr	t9
  44:	00200825 	move	at,at
  48:	8fa40024 	lw	a0,36(sp)
  4c:	3c192ab2 	lui	t9,0x2ab2
  50:	2739c410 	addiu	t9,t9,-15344
  54:	0320f809 	jalr	t9
  58:	00200825 	move	at,at
  5c:	8fbf001c 	lw	ra,28(sp)
  60:	27bd0020 	addiu	sp,sp,32
  64:	03e00008 	jr	ra
  68:	00200825 	move	at,at
  6c:	00000000 	nop

Beim Datum scheint es noch Probleme zu geben:

			DateTime dt = new DateTime (2014, 5, 25, 14, 30, 0);
			Console.WriteLine ("{0}.{1}.{2} {3}:{4}", dt.Day, dt.Month, dt.Year, dt.Hour, dt.Minute);
			Console.WriteLine ("{0}", dt);
			dt = DateTime.Now;
			Console.WriteLine ("{0}.{1}.{2} {3}:{4}", dt.Day, dt.Month, dt.Year, dt.Hour, dt.Minute);
			Console.WriteLine ("{0}", dt);


25.5.2014 14:30
2147483647/918246/2147483148 14:30:00
13.5.2014 15:17
2147483647/0,/1291713560 15:17:04

 

[neolithos]

Langsam sehe ich in den Code durch:

123456789.012345
25.5.2014 14:30
05/25/2014 14:30:00
13.5.2014 16:17
05/13/2014 16:17:28

Für alle dies nachvollziehen wollen:

gelöscht um Verwirrungen zu vermeiden.

 

[RalfFriedl]

Es kann gut sein, dass das Datum als double gespeichert wird, Anzahl von Tagen seit einem Startdatum plus Bruchteile von Tagen für die Uhrzeit, das ist eine gängige Darstellung. In diesem Fall müsstest Du auch die Stelle bei ArgInFRe ändern.

Die Änderung von Dir ist übrigens nur korrekt für Big Endian, für Little Endian war es vorher korrekt und ist jetzt falsch. Korrekt wäre:

--- mono-3.4.0/mono/mini/mini-mips_2.c	Di 13. Mai 16:20:41 2014
+++ mono-3.4.0/mono/mini/mini-mips.c	Mi 19. Feb 19:48:46 2014
@@ -5165,8 +5165,8 @@ mono_arch_emit_prolog (MonoCompile *cfg)
 					break;
 				case 8:
 #if (SIZEOF_REGISTER == 4)
-					mips_sw (code, ainfo->reg, inst->inst_basereg, basereg_offset + ms_word_offset);
-					mips_sw (code, ainfo->reg + 1, inst->inst_basereg, basereg_offset + ls_word_offset);
+					mips_sw (code, ainfo->reg + ls_word_idx, inst->inst_basereg, basereg_offset + ls_word_offset);
+					mips_sw (code, ainfo->reg + ms_word_idx, inst->inst_basereg, basereg_offset + ms_word_offset);
 #elif (SIZEOF_REGISTER == 8)
 					mips_sd (code, ainfo->reg, inst->inst_basereg, basereg_offset);
 #endif

 

[neolithos]

Stimmt muss ja auch noch anders herum gehen.

 

[clay]

Super Nachrichten, dass es Fortschritte gibt!

Inwieweit ist durch diesen Patch Mono lauffähig? Denkt Ihr dieser Patch kommt in die offizielle Version rein?

 

[neolithos]

Keine Ahnung, ich hab ihn mal an den Fehlerbericht als Kommentar angehängt. Der Long,DateTime-Datentyp läuft bei mir, so weit ich das überblicke.

Aber wie sieht es mit Freetz aus? Schafft es jemand dort mal ein Paket zu platzieren bzw. erst einmal eines zu erstellen? Damit man Mono in die Box mit integrieren kann.

 

[clay]

Danke! Werde den MONO Patch mal einbauen und die Mono Sourcen nochmal durchkompilieren und testen...

 

[RalfFriedl]

Du kannst mal in den anderen Paketen nachschauen, wie das dort gemacht wird, und eine Datei mono.mk zum Übersetzen erstellen. Es nützt aber wenig, das einzubauen, solange es nicht richtig läuft.

 

[neolithos]

Es würde vieles vereinfachen. Da größere Projekte Abhängigkeiten haben, die über die mscorlib hinaus gehen. Vielleicht findet sich dann noch Fehler.

Zu Koordination, damit nix doppelt gemacht wird:
@clay bist du da gerade dran? Bzw. wie sieht es bei Dir aus?

 

[clay]

Ich bin gerade dran mono neu zu kompilieren und ein paar Tests zu machen...

 

[clay]

Kennt jemand von EUch das Problem:

C# Sourcecode

 static int Main(string[] args)
        {
            long i1 =  (int.MaxValue +1L);
            Console.WriteLine(i1.ToString());
 
            Console.WriteLine("Hello World!");
            Console.WriteLine(DateTime.Now.ToString());

            return 0;
        }

Ausgabe:

# /var/media/ftp/mono34mips2/bin/mono ConsoleApplication2.exe
2147483648
Hello World!
05/13/2014 20:45:40
/var/media/ftp/mono34mips2/bin/mono: can't resolve symbol '__fpcmp_parts_f'


Der Mono Prozess hängt dann fest und kann nur noch mit Kill aus einer 2ten Session beendet werden....

 

[clay]

hab noch einen Fehler gefunden:

 TimeSpan ts =  TimeSpan.FromMilliseconds(1000);
           Console.WriteLine(ts.Seconds.ToString());

wirft eine Exception.

Unhandled Exception:
System.OverflowException: Resulting timespan is too big.
at System.TimeSpan.From (Double value, Int64 tickMultiplicator) [0x00000] in <filename unknown>:0
at System.TimeSpan.FromMilliseconds (Double value) [0x00000] in <filename unknown>:0
at ConsoleApplication2.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.OverflowException: Resulting timespan is too big.
at System.TimeSpan.From (Double value, Int64 tickMultiplicator) [0x00000] in <filename unknown>:0
at System.TimeSpan.FromMilliseconds (Double value) [0x00000] in <filename unknown>:0
at ConsoleApplication2.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0


Möglicherweise gibt es noch mehr Stellen im MONO-Sourcecode wo gefixt werden muss...

 

[RalfFriedl]

Die Funktion __fpcmp_parts_f ist in libgcc.
So wie es aussieht, ist das Programm an der Stelle doch schon fertig. Starte das Programm mal mit strace:
start -fs2000 /var/media/ftp/mono34mips2/bin/mono ConsoleApplication2.exe

Das Programm strace kann man in Freetz auswählen, es reicht, die das Programm über USB oder Netzwerk auf die Box zu bringen, eine neue Firmware ist nicht notwendig. Wähle am besten auch gleich ltrace mit aus.

 

[neolithos]

Ich hab mal deine Beispiele ausprobiert.

Das erste:

2147483648
Hello World!
05/13/2014 21:15:56

Das zweite Ergibt 0. Das bedeutet vermutlich wir müssen noch irgendwas im Gleitkomma-Zeug finden.

Ich nutze mkbundle für meine Tests. Leitest du das Install einfach in ein beliebiges Verzeichnis um?

 

[clay]

ja, ich nutze den --prefix parameter beim configure, so dass alle dateien in ein eigenes Verzeichnis installiert werden.

Dieses Verzeichnis kopiere ich in den Flashspeicher der Box... In dieses Verzeichnis kopiere ich die managed Komponenten, die ich aus einem funktionierendem x86 mono habe. Somit habe ich ein vollständiges Mono auf der Box im Flash Speicher...

wie genau funktioniert mkbundle? muss dass nicht im Zielsystem (also auf der Box) ausgeführt werden?

@RalfFriedl: Ich bin Anfänger in Sachen Freetz. Wie genau funktioniert das Erstellen von strace? Könntest Du es vielleicht schnell hier hochladen?