000
05.06.2008, 20:58 Uhr
Olli
|
So, ich mal wieder mit meinen bloeden Fragen
Ich bin Z.t dabei die Kernel Quellen welche mir noch fehlten bzw. fehlen durch disassemblieren der Objekte und zurueckverwandeln des ASM Codes in C zu erhalten. Ziel soll ein Kernel in seinen Sourcen sein, der 100% zu den gleichen Objekten compiliert wie sie original im WEGA Kernel vorliegen. Von den durch EAW entwickelten und/oder erweiterten Objekten ist das ja kein Problem da ich von diesen Objekten ja die Sourcen habe. Problematisch sind eher die Objekte welche wohl noch direkt und unveraendert aus ZEUS stammen. Das ist wohl bei einem Grossteil der Objekte aus sys/ bzw. LIB2 der Fall. Aber auch dort habe ich einigen Fortschritt gemacht. Ich habe bereits einen Grossteil der Sourcen wiedergewinnen koennen, stehe jetzt jedoch bei einer Detailfrage vor einem Problem. Ich versuche einen ASM-Code in C nachzubilden, welcher an einigen Stellen im Kernel in den Original-ZEUS-Objekten vorkommt. Und zwar:
Quellcode: | 0530 3582 0004 584 ldl rr2,rr8(#4) 0534 9424 ldl rr4,rr2 0536 0704 7f00 585 and r4,#32512 04d2 5d04 8000* 586 ldl _u+78,rr4 04d6 004e*
|
Vom Verstaendniss her, denke ich schon zu verstehen was dort passiert. ab der 4. Position des Langwortregisters RR8 in das Langwortregister RR2. Danach wird RR2 nach RR4 kopiert. Dann wird der niedere Teil, also R4 mit 7F00 ueber AND verknuepft, und das ganze Ergebniss wird dann zurueck in den User-struct u +78 geladen. Mein C-Code sieht auf Basis dieser Info nun so aus:
u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);
In ASM wird daraus jedoch:
Quellcode: | 0530 3582 0004 584 ldl rr2,rr8(#4) 0536 0702 7f00 and r2,#32512 04d2 5d02 8000* 585 ldl _u+78,rr2 04d6 004e*
|
Da mit rr2 im Original-Code oben nichts weiter passiert, ist meine Implementierung funktional wohl identisch, aber halt nicht von der Anzahl der Instruktionen - was ich aber halt gerne erreichen wuerde. Ich gruebele nun schon tagelang was hier fuer eine Operation stattfinden koennte welche der Optimizer zu einem AND mit 7f00ffff optimiert und beim optimieren halt die register-Kopie "uebrig" bleibt. Ich kommme einfach nicht drauf. Ich habe schon verschiedenste andere Konstrukte wie u.u_dirp.l = (long)((saddr_t *)uap->linkname)->l & 0x7f00ffffL; u.u_dirp.l = ((long)uap->linkname&0x7F00FFFFL); u.u_dirp.l = (long)((int)uap->linkname&0x7F00); versucht. Alles ohne Erfolg... Das ganze hier in dem Fall ist uebrigens aus dem link() Syscall aus sys2.c Zu finden unter
http://cvs.laladev.org/index.html/WEGA/src/uts/sys/sys2.c?rev=1.7&content-type=text/x-cvsweb-markup
Wenn man dort nach link() sucht findet man die Syscall-Implementierung. Der Rest der Kernels sowie die Header-Files sind auch auf der Seite zu finden.
Die Frage ist halt - gibt es andere Operationen die mit einer AND Verknuepfung mit 7F00FFFF identisch sind? Vielleicht stand ja genau sowas im C-Code und erst der Optimizer hat daraus ein AND gemacht... Rein Mathematisch bedeutet das AND ja, das das 1. BIT geloescht wird, genauso wie die BITs 9-16. die Bits 2-8 und 17-32 werden aus dem Original unveraendert uebernommen. Ein Kollege auf Arbeit meinte, es koenne evtl. eine Art Adressermittlung aus einem Speicher-Segment sein? Wer weiss... -- P8000 adventures: http://pofo.de/blog/?/categories/1-P8000 |