MythBuild-ISSUE: Compilation on Windows

1 view
Skip to first unread message

Dario Rodriguez

unread,
Mar 1, 2011, 10:31:26 AM3/1/11
to mythos-devgroup
Inicio este nuevo thread, aunque con una cita:

2011/2/27 Dario Rodriguez <soft....@gmail.com>:
>> Creo que sería conveniente poder compilar el kernel desde Windows, a
>> mi me sería mucho más cómodo por lo menos. Por cierto, el make tiene
>> un fallo: hay que borrar manualmente la carpeta rootfs antes de poder
>> hacer un make iso.
>
> Yo no uso Win, pero si quieres encargarte de ver que Mythos se pueda
> compilar allí, podrías poner la documentación pertinente en una nueva
> rama, y enviar una serie de parches según se describe en el tutorial
> en doc/es.

Creo recordar que nos mencionabas que tu error tenía que ver con el
linker. Descargué el fuente a una máquina con Windows y Cygwin:

$ make
>>> MYTHOS BUILD STARTED AT 2011-03-01 10:36:20
>>> built on CYGWIN_NT-5.1
o> KERNEL OBJECT [src/kernel/main.ko]
o> KERNEL OBJECT [src/kernel/video.ko]
o> KERNEL OBJECT [src/kernel/system.ko]
o> KERNEL OBJECT [src/kernel/sysutils.ko]
o> GENERATING LINKED KERNEL IMAGE [mythKernel]
src/boot/boot.ko: In function `stublet':
./src/boot/boot.asm:(.text+0x19): undefined reference to `MythKernel'
make: *** [mythKernel] Error 1

Entonces se me ocurrio ver un poco el detalle del linkeo, empezando
por la tabla, sin encontrar nada extraño en ella, y siguiendo por
aqui:

$ dump src/kernel/main.ko | head
src/kernel/main.ko:
00000000 4c01 0b00 0000 0000 2c05 0000 1c00 0000 L.......,.......
00000010 0000 0401 2e74 6578 7400 0000 0000 0000 .....text.......
00000020 0000 0000 1c00 0000 cc01 0000 8c04 0000 ........L.......
00000030 0000 0000 0300 0000 2000 3060 2e64 6174 ........ .0`.dat
00000040 6100 0000 0000 0000 0000 0000 0000 0000 a...............
00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060 4000 30c0 2e62 7373 0000 0000 0000 0000 @.0@.bss........
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 8000 30c0 2f34 0000 ..........0@/4..

$ dump src/boot/boot.ko | head
src/boot/boot.ko:
00000000 7f45 4c46 0101 0100 0000 0000 0000 0000 .ELF............
00000010 0100 0300 0100 0000 0000 0000 0000 0000 ................
00000020 4000 0000 0000 0000 3400 0000 0000 2800 @.......4.....(.
00000030 0700 0300 0000 0000 0000 0000 0000 0000 ................
00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060 0000 0000 0000 0000 0100 0000 0800 0000 ................
00000070 0300 0000 0000 0000 6001 0000 0020 0000 ........`.... ..
00000080 0000 0000 0000 0000 0400 0000 0000 0000 ................

No se si se alcanza a comprender la enorme diferencia, observen:

$ cat <<EOF>test.c
> #include <stdio.h>
> int main (int argc,char **argv) {
> puts("HI!");
> }
> EOF

$ gcc -o test.exe test.c

$ ./test.exe
HI!

$ dump test.exe | head
test.exe:
00000000 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............
00000010 b800 0000 0000 0000 4000 0000 0000 0000 8.......@.......
00000020 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030 0000 0000 0000 0000 0000 0000 8000 0000 ................
00000040 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ..:..4.M!8.LM!Th
00000050 6973 2070 726f 6772 616d 2063 616e 6e6f is program canno
00000060 7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS
00000070 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$.......
00000080 5045 0000 4c01 0900 1afb 6c4d 001e 0000 PE..L....{lM....

$ gcc -c test.c

$ dump test.o | head
test.o:
00000000 4c01 0400 0000 0000 0201 0000 0e00 0000 L...............
00000010 0000 0401 2e74 6578 7400 0000 0000 0000 .....text.......
00000020 0000 0000 2c00 0000 b400 0000 e400 0000 ....,...4...d...
00000030 0000 0000 0300 0000 2000 3060 2e64 6174 ........ .0`.dat
00000040 6100 0000 0000 0000 0000 0000 0000 0000 a...............
00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060 4000 30c0 2e62 7373 0000 0000 0000 0000 @.0@.bss........
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 8000 30c0 2e72 6461 ..........0@.rda

...Suena parecido a algo???

$ dump src/kernel/main.ko | head
src/kernel/main.ko:
00000000 4c01 0b00 0000 0000 2c05 0000 1c00 0000 L.......,.......
00000010 0000 0401 2e74 6578 7400 0000 0000 0000 .....text.......
00000020 0000 0000 1c00 0000 cc01 0000 8c04 0000 ........L.......
00000030 0000 0000 0300 0000 2000 3060 2e64 6174 ........ .0`.dat
00000040 6100 0000 0000 0000 0000 0000 0000 0000 a...............
00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060 4000 30c0 2e62 7373 0000 0000 0000 0000 @.0@.bss........
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 8000 30c0 2f34 0000 ..........0@/4..

En conclusion, para lograr la emulación de binarios UNIX like sobre
Windows, Cygwin no interpreta binarios a.out o ELF, y GCC no los
compila. Estamos generando todos los objetos en formato PE para
Windows y pretendiendo linkearlo con el boot.ko, que es un ELF.

La solución es obviamente compilar el resto a ELF, que es el formato
en el que se debe cargar el binario. Y de hecho, estaba planteandome
si ELF no es un formato demasiado complejo para soportar como inicial
para el Kernel.

Quizá sea la opción más sabia para cargar un microkernel, dadas las
incapacidades de a.out y a sabiendas de que en algún momento deberemos
migrar, pero podríamos tardar demasiado en soportar el formato desde
el kernel mismo para cargar los módulos.

Qué dicen al respecto?
--
Saludos,
D4RIO

Reply all
Reply to author
Forward
0 new messages