PSP & desarrollo ASM, comienzo imposible!?

Moderadores: Kravenbcn, largeroliker, fidelcastro, cerealkiller, pspCaracas, dark_sasuke, m0skit0, LnD, ka69, zacky06

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Me faltaba responder a las preguntas que hacían referencia al bit pattern:

Darthvader38 escribió:Mi duda es si yo puedo usar la instruccion "syscall" (no me importa como obtener el # de la syscall en este momento)

Claro, sin problema, pero generalmente no vas a encontrar syscall en medio del código, ni es algo que se suela hacer. Las syscall están en los stubs y realmente no hay razón para no ponerlas ahí.

Darthvader38 escribió:Una conclusion (obvia), es que no me deberia encontrar nunca la instruccion syscall en el desensamblado de un prx porque no es hasta que se carga el prx, que este sabe que syscall corresponde a la funcion que desea usar.

Correcto.

Darthvader38 escribió:tampoco podre saber que "bit parent" corresponde a la instruccion syscall si no es en "tiempo de ejecucion".

No exactamente. La codificación de las instrucciones forma parte del estándar MIPS y la CPU de la PSP cumple con este estándar (pero tiene algunas instrucciones extra). Puedes ver la codificación de las distintas instrucciones aquí (PDF) por ejemplo.

Darthvader38 escribió:que "bit parent" es syscall? ;)

Como te digo, esto realmente es irrelevante. Si quieres ver los códigos de las syscall, haz un dump de un PRX ya cargado en memoria y pásalo por el prxtool. En todo caso, en el documento anterior viene explicado en la página 171. Si te fijas, primero va el opcode (6 bits), que indica que esta es una instrucción especial, luego el número de la syscall (20 bits) y finalmente indica que la instrucción especial en concreto es syscall con los últimos 6 bits con 001100 (6 + 20 + 6 = 32 bits, todas las instrucciones MIPS son 32 bits).

Por tanto por ejemplo syscall 0x2478 sería en código máquina en binario 000000 (opcode) | 0000 0010 0100 0111 1000 (el número de la syscall, 0x2478) | 001100 (función syscall) >> 00000000 00001001 00011110 00001100 >> 0x00091E0C
Imagen

Avatar de Usuario
Darthvader38
Enteradillo
Enteradillo
Mensajes: 67
Registrado: 24 Ene 2010, 06:39

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por Darthvader38 »

Hoy comienzo a hacer algunas pruebas-observaciones :geek: y en un time vuelvo...
Aun no consigo llamar a sceIoOpen si no está como stub en el codigo original (la duda de siempre),
ya me las ingeniaré, si el HBL lo hizo.(tengo varias ideas a probar).
En un rato reviso el pdf ese...
Veremos que sucede m0skit0.
GRANDES SALU2 para ti tio, que te esfuerzas en cubrir hasta el ultimo detalle. :oki:

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Darthvader38 escribió:Aun no consigo llamar a sceIoOpen si no está como stub en el codigo original (la duda de siempre),

Resumiendo: no puedes llamar a una syscall que no está importada de antemano. El único que sabe cuál syscall corresponde a qué llamada.

Darthvader38 escribió:si el HBL lo hizo...

Cómo hace el HBL para adivinar syscalls no es trivial, y además depende de la versión de firmware. Además a partir de no sé qué versión no se pueden adivinar (o por lo menos no sabemos cómo los genera ya que parecen totalmente aleatorias). Lo que hace el HBL es obligar al kerner a cargar otros módulos en memoria (módulo de savegame, por ejemplo) para extraer sus importes resueltos y luego descargarlos.
Imagen

Responder