Add advanced techniques documentation on PRX Module#104
Add advanced techniques documentation on PRX Module#104xeonliu wants to merge 9 commits intopspdev:masterfrom
Conversation
…der for contributing and downloads pages
There was a problem hiding this comment.
Cool! Thanks @xeonliu, this is really useful. I'll go through it fully later. What I can say now is that I feel like we can still improve the navigation on the site here. Maybe the "Advanced Techniques" page that links to "Creating PRX Modules" page, like we do with the installation instructions. There it links to platform specific pages that are not shown in the side bar. What do you think?
It makes sense to me. However I am not sure if Advanced Technique is an appropriate title since I think Debugging is also somewhat an advanced technique 😂 |
Co-authored-by: Copilot <copilot@github.com>
sharkwouter
left a comment
There was a problem hiding this comment.
Hey @xeonliu thanks for updating the layout and for the work on this PR! I made some comments as someone who doesn't work with modules much and doesn't understand them very well. I hope that helps. I think it is great to have this info and the advance techniques page would enable us to document more things that in the past wouldn't really fit on the website :)
|
|
||
| To load a PRX module, the main module needs to know which functions it can call within that module. This is done by creating a stub library, a static library containing the signatures of the functions in the PRX module. The main module links against this stub library and calls the functions in the PRX module just like regular functions. | ||
|
|
||
| The stub library only contains the Module Name, the NID (Native ID?) of the function and a stub implementation of the function. |
There was a problem hiding this comment.
NID stands for name identifier it seems: https://psp-re.github.io/blog/nid-cracking/
There was a problem hiding this comment.
"which I believe stands for Name Identifier"
Maybe I should just explain what it is rather than its real name
|
|
||
| > Guidelines | ||
| > 1. `syslib` is an essential keyword that must be included in the export table. | ||
| > 2. It is generally not recommended to export global variables. (TODO: Reference needed) |
There was a problem hiding this comment.
I think you can remove the TODO here. This makes sense to me without additional context, as the user cannot know what modifies the exported global variable or what effect modifying it will have on the program.
There was a problem hiding this comment.
I believe this restriction is documented in a document which I read before. I couldn't remember where.
| PSP_EXPORT_END | ||
|
|
||
| # Export our function | ||
| PSP_EXPORT_START(MyLib, 0, 0x0001) |
There was a problem hiding this comment.
Maybe it would be good to specify where MyLib comes from.
| PSP_BEGIN_EXPORTS | ||
|
|
||
| # These four lines are mandatory (although you can add other functions like module_stop) | ||
| # syslib is a psynonym for the single mandatory export. |
There was a problem hiding this comment.
I think it is less confusing without this second line.
| # Define the exports for the prx | ||
| PSP_BEGIN_EXPORTS | ||
|
|
||
| # These four lines are mandatory (although you can add other functions like module_stop) |
There was a problem hiding this comment.
I think it would be good to explicitly explain how to export a function below this code example as well.
| ### Compile the PRX Module | ||
| {: .fs-4 .fw-700 } | ||
|
|
||
| If you are using Makefiles, you can add the following lines to your Makefile to compile the PRX module: |
There was a problem hiding this comment.
Is it possible to also add instructions for CMake? We have an example here: https://psp-re.github.io/blog/nid-cracking/
Since we mostly use CMake in our examples on the website.
There was a problem hiding this comment.
Pretty sure yes. CMake can do that.
I choose Makefile because most existing projects still use them.
I think I will provide 2 versions if possible.
| ### Generate the Stub Library | ||
| {: .fs-4 .fw-700 } | ||
|
|
||
| To generate the stub library, first run the following command in the terminal: |
There was a problem hiding this comment.
I think it might be good to specify in this section how this relates to the Makefile/CMake and building more.
There was a problem hiding this comment.
Do we want to cover the coding limitations for prx modules as well? From what I understand using libraries in a module is difficult.
There was a problem hiding this comment.
There seems to be many restrictions. I haven't figured out the exact restrictions yet, only some suggestions.
It would be better if others in the channel can help verify them
But as for my observation, most problem comes from using standard C lib or libstdc++
Use only PSPSDK functions and writing the code in C without crt0 can avoid most problems.
There was a problem hiding this comment.
Okay, I would still merge this if this is not yet included here now. It can be added later. Maybe having one sentence about the limitation would be good for now. I'll leave it up to you.
|
|
||
| Instead of writing a standard `main` function, you write a `module_start` function (called when the module is loaded) and a `module_stop` function (called when unloaded). These functions should return 0 on success and a negative value on failure. | ||
|
|
||
| > Make sure to use at least on function form other modules (for example, `pspDebugScreenPrintf`), otherwise `psp-fixup-imports` will complain `Error, no .lib.stub section found`. |
There was a problem hiding this comment.
| > Make sure to use at least on function form other modules (for example, `pspDebugScreenPrintf`), otherwise `psp-fixup-imports` will complain `Error, no .lib.stub section found`. | |
| > Make sure to use at least one function form other modules (for example, `pspDebugScreenPrintf`), otherwise `psp-fixup-imports` will complain `Error, no .lib.stub section found`. |
Draft for #103
Maybe examples should be more concrete. Wonder if implementation details should be included here.