 Autor
|
Tema: Código basura de GCC? (Leído 7,293 veces)
|
|
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  ), 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  ) 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 
|
|
|
|
« Última modificación: 1 Marzo 2013, 17:18 pm por Eternal Idol 7D »
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
 Desconectado
Mensajes: 5.937
Israel nunca torturó niños, ni lo volverá a hacer.
|
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.
|
|
|
|
« Última modificación: 1 Marzo 2013, 18:26 pm por Eternal Idol 7D »
|
En línea
|
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
|
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:  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) |
|
|
|
« Última modificación: 3 Marzo 2013, 18:32 pm por Eternal Idol 7D »
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.937
Israel nunca torturó niños, ni lo volverá a hacer.
|
¿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.
|
|
|
|
|
En línea
|
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
|
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: Que es la que ejecuta los bytes en la variable "programa". No sé que está pasando, en serio; ya probé de todo  |
|
|
|
« Última modificación: 3 Marzo 2013, 19:07 pm por lweb20 »
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.937
Israel nunca torturó niños, ni lo volverá a hacer.
|
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..
|
|
|
|
« Última modificación: 3 Marzo 2013, 19:47 pm por Eternal Idol 7D »
|
En línea
|
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
|
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. 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 ( ) tiene un problema similar xD Gracias por todo. Problema solucionado  YEAH  |
|
|
|
« Última modificación: 3 Marzo 2013, 22:48 pm por lweb20 »
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.937
Israel nunca torturó niños, ni lo volverá a hacer.
|
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  |
|
|
|
|
En línea
|
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
|
increible gracias Fíjate el la solución 2 ya no uso el pusha ni el popa (aunque no lo dije ). Creo que el problema fue que nunca liberé la memoria del buffer ya que la moví directamente a 0x10000.
|
|
|
|
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.937
Israel nunca torturó niños, ni lo volverá a hacer.
|
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.
|
|
|
|
|
En línea
|
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
|
|
|
|
 |
