Hi guys,
How can I know if a function I'm using runs in either kernel mode or user mode?
It would be nice to add it to docs in the .h files.
user/kernel API how do identify them on the SDK API?
Thanks, that's a good start, still related to the initial question but maybe a bit off topic, does anyone know how can i use the http://silverspring.lan.st doc,stubs information?
I see that there are some new functions decoded however there is no info on return values/arguments, is there a place to see it? or this hasn't been decoded yet?
I see that there are some new functions decoded however there is no info on return values/arguments, is there a place to see it? or this hasn't been decoded yet?
-
- Posts: 110
- Joined: Tue Feb 27, 2007 9:43 pm
- Contact:
Yep look at the lib name. Some say ___ForUser and some say ___ForKernel
Eg.
IoFileMgrForUser
IoFileMgrForKernel
LoadExecForUser
LoadExecForKernel
If the libname start with sce then the ones with _driver at the end are kernel libs.
Eg.
sceCtrl
sceCtrl_driver
scePower
scePower_driver
If it doesnt have the _driver suffix then it's almost certainly a user lib.
Also almost all usermode functions have kernelmode equivalents.
Regarding the libdocs, I added the stubs with updated functions so you can add to the OBJS = in your makefile to use them.
They are new-style stubs but to be honest I never got the new-style stubs to work, only the old-style stubs.
will create an old-style stub for somemodule.prx. Then just add to OBJS in your makefile.
Or alternatively you can create the stub from an individual module's xml. Download an xml, eg. http://silverspring.lan.st/1.5x/kd/i2c.xml and
add sceI2c_driver.o to the OBJS and start using one of the functions in your app.
Regarding the prototype for a particular function, it's upto the dev to work out the prototype and proper usage if they want to use the function. The api is too large to fully document so it's upto each individual to work it out themselves. You don't need to create a .h file, as long as you pass the correct arguments that the function is expecting (though the compiler will throw you a warning).
The libdoc.xml can also be used in prxtool to resolve symbols for disassembly.
will disassemble somemodule.prx with the updated names added in the libdoc.
or alternatively
will create an IDC script to use in IDA disassembly.
Eg.
IoFileMgrForUser
IoFileMgrForKernel
LoadExecForUser
LoadExecForKernel
If the libname start with sce then the ones with _driver at the end are kernel libs.
Eg.
sceCtrl
sceCtrl_driver
scePower
scePower_driver
If it doesnt have the _driver suffix then it's almost certainly a user lib.
Also almost all usermode functions have kernelmode equivalents.
Regarding the libdocs, I added the stubs with updated functions so you can add to the OBJS = in your makefile to use them.
They are new-style stubs but to be honest I never got the new-style stubs to work, only the old-style stubs.
Code: Select all
prxtool -n libdoc.xml -u somemodule.prx
will create an old-style stub for somemodule.prx. Then just add to OBJS in your makefile.
Or alternatively you can create the stub from an individual module's xml. Download an xml, eg. http://silverspring.lan.st/1.5x/kd/i2c.xml and
Code: Select all
prxtool -t i2c.xml
Regarding the prototype for a particular function, it's upto the dev to work out the prototype and proper usage if they want to use the function. The api is too large to fully document so it's upto each individual to work it out themselves. You don't need to create a .h file, as long as you pass the correct arguments that the function is expecting (though the compiler will throw you a warning).
The libdoc.xml can also be used in prxtool to resolve symbols for disassembly.
Code: Select all
prxtool -n libdoc.xml -o somemodule.asm -w somemodule.prx
or alternatively
Code: Select all
prxtool -n libdoc.xml -o somemodule.idc -c somemodule.prx