Código basura de GCC?

Iniciado por lweb20, 1 Marzo 2013, 01:12 AM

0 Miembros y 1 Visitante están viendo este tema.

lweb20

EI: del Cache de Google:
cache:http://foro.elhacker.net/programacion_cc/codigo_basura_de_gcc-t384404.0.html





Hola a todos. A ver a ver cómo empezar...

Antes que nada, me disculpo de la forma cómo hablo ya que no soy muy bueno escribiendo en foros (sí en blogs, por ejemplo el mío). No quiero ofender a nadie.

Bueno, estoy programando un sistema operativo de 32 bits como hobby (No soy un novato más). Estuve como 5 meses leyendo y leyendo (claro, aparte del tiempo que estuve estudiando por mi cuenta asm de 16 bits - no mucho pero me sirvió para hacer un micro-so :P), haciendo pruebas y encontré un manual de paso a paso cómo iniciar un kernel. Bueno ya tengo mi kernel que inicia el GDT, IDT, el teclado, la disquetera, y algunas otras cosas (no menos importantes).

La cosa es que estuve programando y re-programando (volviendo a programar para corregir errores y mejorarlos) algunos drivers básicos (ya saben) y como tenía tanto código cada compilada se comenzaba a demorar más y más en compilar (y nada en ejecutar :D) y se me ocurrió cargar un archivo en la memoria y luego ejecutarlo (call).

Como siempre estuve haciendo pruebas tras pruebas, investigando como loco y cuando me puse a descansar un rato se me vino la solución a la cabeza y listo! pude ejecutar un archivo ensamblado con nasm en mi kernel usando una interrupción del IDT (int 0x80 - mostrar un texto en la pantalla) y todo funciona ok.

Ahora quise que un programa compilado con un lenguaje de alto nivel (C) se pudiera ejecutar en mi kernel y después de 2 días pude lograrlo.. A medias... Lo que pasa es que me ejecuta el código pero cuando termina la ejecución se genera un page fault (excepción) y estuve revisando el por qué, adjunto el código del archivo de C, el linker script, el batch y las imágenes que tengo:


LINKER SCRIPT (los comentarios que ves los agregué al postear)

ENTRY("_inicio")
SECTIONS
{
   . = 0x10000; // Aquí es donde ubica el kernel al programa
//lo demás no lo entiendo (no voy a mentir) aunque me solucionó un problema anterior (googleando lo encontré)
   .text :
   {
       code = .;
       *(.text)
       text_end = .;
   }
   .rodata :
   {
       rodata = rodata_end;
       *(.rodata)
       rodata_end  = .;    
   }  
   .rdata :
   {
       rdata = rdata_end;
       *(.rodata)
       rdata_end  = .;    
   }
   .data :
   {
       data = data_end;
       *(.data)
       data_end = .;
   }
   .bss :
   {
       bss = bss_end;
       *(.bss)
       bss_end = .;
   }
   end = .;
           /DISCARD/ :{
               *(.note*)
               *(.indent)
               *(.comment)
               *(.stab)
               *(.stabstr)
       }
}


PROGRAMA EN C (GCC)
void inicio(){
char* imprimir = "Hola mundo desde GCC (Intel Syntax, programa.exe) v2!";
asm(
"xor eax, eax\n" // función 0
"mov ebx, %0\n" // cadena
"int 0x80\n" // llama a la interrupción del kernel
:
: "m"(imprimir)
);
return;
}


BATCH

// Yo mismo lo hice xD

:X
cls

gcc -march=i686 -std=gnu99 -ffreestanding -c test.c -masm=intel // aquí hay un problema a mi parecer
ld -o test -Tlink.ld test.o //creo el archivo PE
objcopy -S -O binary test ..\programa.exe //genero un archivo binario en base al archivo PE
pause
goto X


Bueno acá van las imágenes.

1. Aquí veo un código "basura" el cual me parece que mi kernel no lo entiende o no sé que sea :S

CÓDIGO OBJETO OBTENIDO POR GCC. Lo seleccionado es lo que me parece que es el problema.



2. Aquí se repite el código. Extrañamente se fue al final del archivo binario :¬¬




Cuando borro el código seleccionado manualmente en el binario se ejecuta mi programa normalmente.

Por cierto mis primeros lenguajes de programación entre comillas fueron HTML, javascript (tenía 9 años xD), después a los 13 aprendí VB.NET que es el lenguaje que siento que soy muy bueno (llevo años..) y a los 17 (masomenos) aprendí C++ (me adapté al C luego :p) y asm tuve que estudiarlo a la fuerza (obviamente no soy tan bueno pero me defiendo). Todo esto fue por mi cuenta.

No sé si alguien podría ayudarme o darme una pista para poder entender qué cosa es ese código que sobra y cómo podría eliminarlo o no ejecutarlo.

POSDATA: Mi kernel ejecuta desde el indice 0 del archivo (no ejecuta PE ni ELF, sólo binarios)

Gracias por haber leído tal discurso :)

Eternal Idol

#1
Usando dumpbin del VC++ en test.o:



Dump of file test.o

File Type: COFF OBJECT

FILE HEADER VALUES
            14C machine (x86)
              5 number of sections
              0 time date stamp Thu Jan 01 01:00:00 1970
            178 file pointer to symbol table
              E number of symbols
              0 size of optional header
            104 characteristics
                  Line numbers stripped
                  32 bit word machine

SECTION HEADER #1
  .text name
      0 physical address
      0 virtual address
     18 size of raw data
     DC file pointer to raw data (000000DC to 000000F3)
    164 file pointer to relocation table
      0 file pointer to line numbers
      1 number of relocations
      0 number of line numbers
60300020 flags
        Code
        4 byte align
        Execute Read

RAW DATA #1
 00000000: 55 89 E5 83 EC 10 C7 45 FC 00 00 00 00 31 C0 8B  U.å.ì.ÇEü....1À.
 00000010: 5D FC CD 80 C9 C3 90 90                          ]üÍ.ÉÃ..

RELOCATIONS #1
                                               Symbol    Symbol
Offset    Type              Applied To         Index     Name
--------  ----------------  -----------------  --------  ------
00000009  DIR32                      00000000         A  .rdata

SECTION HEADER #2
  .data name
      0 physical address
      0 virtual address
      0 size of raw data
      0 file pointer to raw data
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
C0300040 flags
        Initialized Data
        4 byte align
        Read Write

SECTION HEADER #3
   .bss name
      0 physical address
      0 virtual address
      0 size of raw data
      0 file pointer to raw data
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
C0300080 flags
        Uninitialized Data
        4 byte align
        Read Write

SECTION HEADER #4
 .rdata name
      0 physical address
      0 virtual address
     38 size of raw data
     F4 file pointer to raw data (000000F4 to 0000012B)
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
40300040 flags
        Initialized Data
        4 byte align
        Read Only

RAW DATA #4
 00000000: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65  Hola mundo desde
 00000010: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74   GCC (Intel Synt
 00000020: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65  ax, programa.exe
 00000030: 29 20 76 32 21 00 00 00                          ) v2!...

SECTION HEADER #5
     /4 name (.eh_frame)
      0 physical address
      0 virtual address
     38 size of raw data
    12C file pointer to raw data (0000012C to 00000163)
    16E file pointer to relocation table
      0 file pointer to line numbers
      1 number of relocations
      0 number of line numbers
40300040 flags
        Initialized Data
        4 byte align
        Read Only

RAW DATA #5
 00000000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01  .........zR..|..
 00000010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00  ................
 00000020: 04 00 00 00 16 00 00 00 00 41 0E 08 85 02 42 0D  .........A....B.
 00000030: 05 52 C5 0C 04 04 00 00                          .RÅ.....


RELOCATIONS #5
                                               Symbol    Symbol
Offset    Type              Applied To         Index     Name
--------  ----------------  -----------------  --------  ------
00000020  REL32                      00000004         4  .text

COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
   test.c
002 00000000 SECT1  notype ()    External     | _inicio
   tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1  notype       Static       | .text
   Section length   16, #relocs    1, #linenums    0, checksum        0
006 00000000 SECT2  notype       Static       | .data
   Section length    0, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT3  notype       Static       | .bss
   Section length    0, #relocs    0, #linenums    0, checksum        0
00A 00000000 SECT4  notype       Static       | .rdata
   Section length   36, #relocs    0, #linenums    0, checksum        0
00C 00000000 SECT5  notype       Static       | .eh_frame
   Section length   38, #relocs    1, #linenums    0, checksum        0

String Table Size = 0x18 bytes

 Summary

          0 .bss
          0 .data
         38 .eh_frame
         38 .rdata
         18 .text



Idem en el test:

Dump of file test

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
            14C machine (x86)
              3 number of sections
       5130DE02 time date stamp Fri Mar 01 17:57:38 2013
            A00 file pointer to symbol table
             27 number of symbols
             E0 size of optional header
            307 characteristics
                  Relocations stripped
                  Executable
                  Line numbers stripped
                  32 bit word machine
                  Debug information stripped

OPTIONAL HEADER VALUES
            10B magic # (PE32)
           2.22 linker version
            200 size of code
            400 size of initialized data
              0 size of uninitialized data
       FFC10000 entry point (100010000)
       FFC10000 base of code
              0 base of data
         400000 image base (00400000 to 100011FFF)
           1000 section alignment
            200 file alignment
           4.00 operating system version
           1.00 image version
           4.00 subsystem version
              0 Win32 version
       FFC12000 size of image
            200 size of headers
           F21E checksum
              3 subsystem (Windows CUI)
              0 DLL characteristics
         200000 size of stack reserve
           1000 size of stack commit
         100000 size of heap reserve
           1000 size of heap commit
              0 loader flags
             10 number of directories
              0 [       0] RVA [size] of Export Directory
              0 [       0] RVA [size] of Import Directory
              0 [       0] RVA [size] of Resource Directory
              0 [       0] RVA [size] of Exception Directory
              0 [       0] RVA [size] of Certificates Directory
              0 [       0] RVA [size] of Base Relocation Directory
              0 [       0] RVA [size] of Debug Directory
              0 [       0] RVA [size] of Architecture Directory
              0 [       0] RVA [size] of Global Pointer Directory
              0 [       0] RVA [size] of Thread Storage Directory
              0 [       0] RVA [size] of Load Configuration Directory
              0 [       0] RVA [size] of Bound Import Directory
              0 [       0] RVA [size] of Import Address Table Directory
              0 [       0] RVA [size] of Delay Import Directory
              0 [       0] RVA [size] of COM Descriptor Directory
              0 [       0] RVA [size] of Reserved Directory


SECTION HEADER #1
  .text name
     18 virtual size
FFC10000 virtual address (100010000 to 100010017)
    200 size of raw data
    200 file pointer to raw data (00000200 to 000003FF)
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
60300020 flags
        Code
        RESERVED - UNKNOWN
        RESERVED - UNKNOWN
        Execute Read

RAW DATA #1
 100010000: 55 89 E5 83 EC 10 C7 45 FC 18 00 01 00 31 C0 8B U.å.ì.ÇEü....1À.
 100010010: 5D FC CD 80 C9 C3 90 90                         ]üÍ.ÉÃ..

SECTION HEADER #2
 .rdata name
     38 virtual size
FFC10018 virtual address (100010018 to 10001004F)
    200 size of raw data
    418 file pointer to raw data (00000418 to 00000617)
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
40300040 flags
        Initialized Data
        RESERVED - UNKNOWN
        RESERVED - UNKNOWN
        Read Only

RAW DATA #2
 100010018: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65 Hola mundo desde
 100010028: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74  GCC (Intel Synt
 100010038: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65 ax, programa.exe
 100010048: 29 20 76 32 21 00 00 00                         ) v2!...

SECTION HEADER #3
.eh_fram name
     38 virtual size
FFC11000 virtual address (100011000 to 100011037)
    200 size of raw data
    800 file pointer to raw data (00000800 to 000009FF)
      0 file pointer to relocation table
      0 file pointer to line numbers
      0 number of relocations
      0 number of line numbers
40300040 flags
        Initialized Data
        RESERVED - UNKNOWN
        RESERVED - UNKNOWN
        Read Only

RAW DATA #3
 100011000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01 .........zR..|..
 100011010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00 ................
 100011020: E0 EF FF FF 16 00 00 00 00 41 0E 08 85 02 42 0D àïÿÿ.....A....B.
 100011030: 05 52 C5 0C 04 04 00 00                         .RÅ.....


COFF SYMBOL TABLE
000 0000000A DEBUG  notype       Filename     | .file
   test.c
002 00000000 SECT1  notype ()    External     | _inicio
   tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1  notype       Static       | .text
   Section length   16, #relocs    1, #linenums    0, checksum        0
006 00000000 SECT2  notype       Static       | .rdata
   Section length   36, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT3  notype       Static       | .eh_frame
   Section length   38, #relocs    1, #linenums    0, checksum        0
00A 00000000 SECT2  notype       External     | rdata
00B 00000000 SECT2  notype       External     | rdata_end
00C 00000000 ABS    notype       External     | __dll_characteristics__
00D 00001000 ABS    notype       External     | __size_of_stack_commit__
00E 00200000 ABS    notype       External     | __size_of_stack_reserve__
00F 00000004 ABS    notype       External     | __major_subsystem_version__
010 00000018 SECT1  notype       External     | text_end
011 00001000 ABS    notype       External     | __size_of_heap_commit__
012 00000000 ABS    notype       External     | __dll__
013 00000000 ABS    notype       External     | __minor_os_version__
014 00400000 ABS    notype       External     | __image_base__
015 00001000 ABS    notype       External     | __section_alignment__
016 00011038 ABS    notype       External     | end
017 00000038 SECT3  notype       External     | bss_end
018 00000038 SECT3  notype       External     | bss
019 00000200 ABS    notype       External     | __file_alignment__
01A 00000038 SECT3  notype       External     | data
01B 00000004 ABS    notype       External     | __major_os_version__
01C 00100000 ABS    notype       External     | __size_of_heap_reserve__
01D 00400000 ABS    notype       External     | ___ImageBase
01E 00000003 ABS    notype       External     | __subsystem__
01F 00000000 SECT2  notype       External     | rodata_end
020 00000001 ABS    notype       External     | __major_image_version__
021 00000000 ABS    notype       External     | __loader_flags__
022 00000000 SECT1  notype       External     | code
023 00000000 ABS    notype       External     | __minor_subsystem_version__
024 00000000 ABS    notype       External     | __minor_image_version__
025 00000000 SECT2  notype       External     | rodata
026 00000038 SECT3  notype       External     | data_end

String Table Size = 0x195 bytes

 Summary

       1000 .eh_fram
       1000 .rdata
       1000 .text




De cualquier manera no se como eso pueda afectar, antes esta el codigo (y la sección .rdata tambien) y este termina con un ret por lo cual deberia devolver el control al Kernel ... no me gusta adivinar y sin tener el resto del sistema es lo unico que podemos hacer. ¿Seguro ves el mensaje en pantalla antes de la excepcion? ¿Seguro cargaste el programa.exe en 0x10000, no? Si _inicio no es 0x10000 es facil que se genere una excepcion al acceder a cualquier parte ... la cadena tiene que estar en la direccion de memoria 0x10018 para que funcione ...

_inicio:
 00000000: 55                 push        ebp
 00000001: 89 E5              mov         ebp,esp
 00000003: 83 EC 10           sub         esp,10h
 00000006: C7 45 FC 00 00 00  mov         dword ptr [ebp-4],offset .rdata
           00
 0000000D: 31 C0              xor         eax,eax
 0000000F: 8B 5D FC           mov         ebx,dword ptr [ebp-4]
 00000012: CD 80              int         80h
 00000014: C9                 leave
 00000015: C3                 ret
 00000016: 90                 nop
 00000017: 90                 nop

PD. Esta no es una pregunta sobre C/C++ sino sobre un compilador en particular, nadie mejor que el desarrollador del mismo para responderte con precision.
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

lweb20

#2
Sí, el programa se carga en esa dirección de memoria. Uso memmove para mover los datos a esa dirección de memoria. Me muestra el mensaje, y también me parece extraño que se ejecute el otro código (ya que sale con un ret). ¿Alguna idea? Investigaré un poco más mi código en estas horas.



EI: juntando mensajes. No escribas mensajes consecutivos, edita.



Bueno, estuve revisando y encontré una supuesta solución (no funciona):

gcc -march=i686 -std=gnu99 -ffreestanding -c test.c -masm=intel
strip -R .eh_frame test.o
ld -o test -Tlink.ld test.o
objcopy -S -O binary test ..\programa.exe

¿está bien quitar esa sección? porque ahora no me muestra ningún mensaje. Cualquier noticia vuelvo a publicar.

EDIT:

Quedó así con el ndisasm:

00000000  55                push ebp
00000001  89E5              mov ebp,esp
00000003  83EC10            sub esp,byte +0x10
00000006  C745FC00000000    mov dword [ebp-0x4],0x0
0000000D  31C0              xor eax,eax
0000000F  8B5DFC            mov ebx,[ebp-0x4]
00000012  CD80              int 0x80
00000014  C9                leave
00000015  C3                ret
00000016  90                nop
00000017  90                nop
00000018  48                dec eax
00000019  6F                outsd
0000001A  6C                insb
0000001B  61                popad
0000001C  206D75            and [ebp+0x75],ch
0000001F  6E                outsb
00000020  646F              fs outsd
00000022  20646573          and [ebp+0x73],ah
00000026  6465204743        and [gs:edi+0x43],al
0000002B  43                inc ebx
0000002C  2028              and [eax],ch
0000002E  49                dec ecx
0000002F  6E                outsb
00000030  7465              jz 0x97
00000032  6C                insb
00000033  205379            and [ebx+0x79],dl
00000036  6E                outsb
00000037  7461              jz 0x9a
00000039  782C              js 0x67
0000003B  207072            and [eax+0x72],dh
0000003E  6F                outsd
0000003F  677261            jc 0xa3
00000042  6D                insd
00000043  61                popad
00000044  2E657865          gs js 0xad
00000048  2920              sub [eax],esp
0000004A  7632              jna 0x7e
0000004C  2100              and [eax],eax
0000004E  0000              add [eax],al


Y adjunto la imagen resultante (archivo final):



Sigo sin comprender por qué tanto código (disculpa la ignorancia) ya que mi código en nasm sólo hice esto:

[bits 32]
[org 0x10000]

jmp codigo
stringToPrint db "Hola mundo!", 0

codigo:
xor eax, eax
mov ebx, stringToPrint
int 0x80
ret 0



EDIT 2:

:o

Y ahora que lo reviso bien el código no me genera ninguna excepción hasta que intento ejecutar el mismo comando. Voy adelantando: mi sistema usa una línea de comandos con múltiples pantallas (eso es lo de menos). Me explico mejor: el comando "ejecutar" (es temporal) ejecuta el programa "programa.exe" con normalidad (sin el strip) hasta que escribo el mismo comando y PAGE FAULT!. Lo más extraño es que funciona normal con nasm, y como ya había mensionado con el gcc pero quitando los supuestos bytes "basura" (garbage)

Eternal Idol

¿Ejecuta el programa sin problemas una vez? Entonces esta claro que el problema es tu sistema y no los bytes posteriores al ret que nunca se llegan siquiera a ejecutar.
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

lweb20

#4
Sí, tienes razón. Estuve revisando y el problema desaparece al quitar el "free" del administrador de memoria. Extraño.. super extraño. Ahí voy a sufrir ya que es muy complejo ese administrador de memoria :S


EDIT 1:

Pero aún así quiero saber qué son esas instrucciones (como dije no soy experto en asm). Por qué el gcc las crea y para qué. Sólo por curiosidad; y ¿está bien quitar la sección con strip?

EDIT 2:

Estoy probando el administrador de memoria con un ejemplo pequeño - usando 100000 bytes de memoria - y no me presenta problemas. Puede ser que la posición de memoria asignada por el programa ejecutable no sea la adecuada o algo así. Esa parte la tengo que estudiar bien. De todas maneras gracias por sacarme de varias dudas.

EDIT 3:

Alaa otro problema: El administrador de memoria parece estar bien. Resulta que todo está bien cuando descomento esta línea:

_asm call programa

Que es la que ejecuta los bytes en la variable "programa". No sé que está pasando, en serio; ya probé de todo :(

Eternal Idol

#5
No son instrucciones, no es codigo, si te fijas es una sección de solo lectura ("Read Only" dice en el output de dumpbin).

Depura instruccion por instruccion hasta ver en cual falla exactamente y ahi mira los registros, la pila, etc..
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

lweb20

#6
Acabo de hacer una depuración simple y el error está en call. Depuración simple es para mi por ejemplo:


PSEUDOCÓDIGO:

IMPRIMIR "leer archivo - inicio"
LEER_ARCHIVO
IMPRIMIR "leer archivo - fin"
etc...

Cualquier novedad aviso. Ahora voy a depurar con bochs

EDIT

Luego de corregir un problema que tenía con el bochs y la disquetera he descubierto algo que no tiene mucho sentido.  :o

El error sigue ocurriendo pero cuando imprimo el contenido de la variable con un for y luego ejecuto el programa funciona todo correctamente.

Explicándome mejor:

Al solamente ejecutar el código con call sucede el page fault pero al imprimir la memoria de la variable en los dos casos (antes de copiarla a 0x10000 y después de copiarla) todo funciona normal.


EDIT 2

Una consulta. Por partes del manual que lei vi que se corregían algunos errores como ese page fault aumentando o disminuyendo el registro esp; ¿qué es lo que hace ese registro? no lo entiendo.


¡NOTICIA!

SOLUCIONÉ EL PROBLEMA

_asm pusha
_asm call programa
_asm popa

Pues lo que hice fue poner en el stack a los registros y luego liberarlos. Pero aún no entiendo el por qué :S ¿Alguien sabe la respuesta?

NOTICIA 2:

La solución era:

1. Abrir el archivo
2. Crear un buffer para los datos del archivo (malloc)
3. Leer el archivo y almacenarlo en el buffer
4. CREAR OTRA VARIABLE con la dirección de memoria 0x10000
5. Copiar el contenido del buffer a 0x10000
6. Liberar el buffer (free)
7. Ejecutar 0x10000
8. NO Liberar 0x10000 (no se debe liberar)

Gracias y ahí está la solución por si alguna otra persona como yo (:P) tiene un problema similar xD

Gracias por todo. Problema solucionado




YEAH  ::)

Eternal Idol

ESP = EXTENDED STACK POINTER. Es justamente el puntero a la pila (stack).

Por lo que pude entender el problema era que tu Kernel (asumo que esta escrito en C/C++) no contaba con lo que podia pasar en la funcion a la que llamabas por lo que si el compilador usaba algun registro (en este caso deberia ser EBX) para contener un puntero por ejemplo despues al hacer el call programa ese codigo lo cambiaba y entonces ... en fin ... ahora preservas los registros y funciona.


Si tenes ganas de probar podes ver que pasa si en lugar de usar inline assembly usas C:
((void (*)(void))programa)();

Comparando el codigo ensamblador de tu Kernel podras ver si usaba EBX y si el compilador decide cambiar las cosas de alguna manera  :silbar:
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón

lweb20

:o increible gracias :)

Fíjate el la solución 2 ya no uso el pusha ni el popa (aunque no lo dije :P). Creo que el problema fue que nunca liberé la memoria del buffer ya que la moví directamente a 0x10000.

Eternal Idol

De nada; y bueno, vaya uno saber, sin ver el codigo nada mas se puede adivinar pero si el problema era de memoria tiene sentido que funcionara una vez. Igual la clave esta en que puedas depurar en ensamblador instruccion por instruccion tu codigo, asi vas a ver siempre donde falla exactamente.
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón