DaXHordes.org

Vamos a ver... ¿Un PRX de 60Ks? ¿Un desensamblado de 15k líneas? ¿Qué parte de "hazte un "Hello world" con el PSPSDK y vemos el PRX resultante" no hemos entendido?

¿Y cómo es posible que el "RAR" tenga 5 descargas ya?

m0skit0 escribió:¿Y cómo es posible que el "RAR" tenga 5 descargas ya?

La gente descarga lo primero que pilla pa' ver qué es. Aunque sea un plugin que le borre toda la flash en un arranque y se queden con un precioso e instantáneo brick. xD

DaniPhii escribió:La gente descarga lo primero que pilla pa' ver qué es. Aunque sea un plugin que le borre toda la flash en un arranque y se queden con un precioso e instantáneo brick. xD

He!
Que se sepa que por un pequeño accidente no subi el SRC.
Asi que lo subo todo de nuevo en un rar con el src INCLUIDO.
Salu2!

M0skit0, no entiendo la queja, cual es el problema con lo que subi!?
Lo que me falto el src...
Si es por el tamaño del prx, siempre crece el size nada mas que declaro
el pspDebugScreenInit();

Empezamos?
(Estare ausente par de dias despues de este mensaje,
salu2 hasta entonces!)

Nada. Me cago en pspDebugScreenInit().

1-Cuando dices(en el ->http://daxhordes.org/forum/viewtopic.php?f=33&t=9802) que:

"todos los codigos de los stubs son"

jr $ra
nop

"son sustituidos por"

jr $ra
syscall <número de syscall>

Significa esto que la instruccion syscall que lei en
el curso solo la usa el sistema porque sabe el # de la syscall
que debe llamar?
Mi duda es si yo puedo usar la instruccion "syscall" (no me importa como obtener el #
de la syscall en este momento) deseo saber si corresponde la instruccion al mismo
"bit parent" del curso.

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.
Por lo tanto, tampoco podre saber que "bit parent" corresponde a la instruccion
syscall si no es en "tiempo de ejecucion".
Es esto correcto?
Espero q me haya dado a entender.
Finalmente y de nuevo, que "bit parent" es syscall?



2-Otra duda: Es el firmware el encargado de guardar y cargar toda la informacion de los registros
en una pila cada vez que se ejecuta otro hilo de ejecucion perteneciente a otro modulo?
Digo, un hilo de otro modulo tendria sus propios valores con los que trabaja en los registros,
cuando le llega su "turno" de ejecucion, el firmware tendria que guardar todos los valores del hilo anterior en una
pila y entonces cargar los pertenecientes al nuevo hilo para que este siga su trabajo?
Es esta suposicion correcta?


Salu2 DaxH + M0skit0!

Significa esto que la instruccion syscall que lei en el curso solo la usa el sistema porque sabe el # de la syscall que debe llamar?

No entiendo muy bien a qué te refieres con "solo la usa el sistema".

Mi duda es si yo puedo usar la instruccion "syscall" (no me importa como obtener el # de la syscall en este momento) deseo saber si corresponde la instruccion al mismo "bit parent" del curso.
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. Por lo tanto, tampoco podre saber que "bit parent" corresponde a la instruccion
syscall si no es en "tiempo de ejecucion". Es esto correcto? Espero q me haya dado a entender. Finalmente y de nuevo, que "bit parent" es syscall?

Lo siento, no sé qué es "bit parent".

Otra duda: Es el firmware el encargado de guardar y cargar toda la informacion de los registros en una pila cada vez que se ejecuta otro hilo de ejecucion perteneciente a otro modulo?

Correcto, eso es el contexto del hilo, pero ten en cuenta que la PSP no es realmente multitarea. Es decir, el kernel no hace cambio de contexto hasta que no se llama a una syscall. De ahí que la PSP se cuelgue por completo en caso de un bucle infinito sin llamada al sistema en modo usuario. En este caso el chip syscon comprueba un registro que el kernel modifica cada vez que es llamado. Si este registro no cambia de valor en X tiempo, el syscon apaga la consola.

Error!-> "bit pattern". <- de aqui lo que queria saber es la representacion binaria de la
instruccion syscall por si deseara hacer un patch.

Sobre las syscall's, quise decir que no tiene
sentido intentar llamarlas si no sabemos cual es cual.
(Cuando digo intentar llamarlas es bajo la DIRECTA declaracion de "syscall")
Ej: syscall 0x01b4 <- De donde puedo asumir que esto es sceIoOpen?!
Quiero decir, el firmware es quien las usa bajo la
declaracion syscall 0x02b4...
nosotros lo que usamos son stubs que luego el firmware determina
si sustituye el stub(por syscall) o salta a la funcion si es modo usuario.Entendi bien esto?

Salu2!

Darthvader38 escribió:Error!-> "bit pattern". <- de aqui lo que queria saber es la representacion binaria de la instruccion syscall por si deseara hacer un patch.

¿Crees que voy a acordarme de la representación binaria de una instrucción? Lo siento pero no Lo puedes ver en el manual oficial de MIPS. De todas formas no necesitas buscar ninguna representación binaria para parchear, eso se suele hacer con el desensamblado y mirando los desplazamientos (offsets). El desensamblado igualmente incluye el código máquina (se llama código máquina, machine code, no bit pattern ). Tú olvídate del código máquina y la representación de las instrucciones en binario, eso es 1) aleatorio (es decir, cada fabricante tiene su propio lenguaje máquina) y 2) trivial (es fácil trabajar con él).

Darthvader38 escribió:Sobre las syscall's, quise decir que no tiene sentido intentar llamarlas si no sabemos cual es cual. (Cuando digo intentar llamarlas es bajo la DIRECTA declaracion de "syscall") Ej: syscall 0x01b4 <- De donde puedo asumir que esto es sceIoOpen?! Quiero decir, el firmware es quien las usa bajo la declaracion syscall 0x02b4... nosotros lo que usamos son stubs que luego el firmware determina si sustituye el stub(por syscall) o salta a la funcion si es modo usuario.Entendi bien esto?

Sí, eso es. El kernel es el único que sabe qué syscall corresponde con qué función, y también ten en cuenta que las syscalls son aleatorizadas cada vez que se resetea el kernel. Pero ten en cuenta que el kernel sustituye los stubs, pero es tu código en modo usuario el que las llama, no el kernel. El kernel simplemente carga el módulo en memoria y luego hace las operaciones que deba sobre él (por ejemplo, resolver los stubs, relocalizar, etc...). De hecho syscall es precisamente para pasar de modo usuario a modo kernel.

PD: tío, deja de meter "enters" por todo el texto, me pones nervioso xD