What is the recommended best practice for late binding (e.g. pspnet libraries) while using the PSPSDK? I could include a startup.s for each project, but based on the example Makefiles that come with the SDK, it would seem the PSPSDK encourages using a "shared" startup.s.
I ask this because I feel our community will evolve as we begin to consistently use the same methods/tools/patterns for developing homebrew.
In reading through the code of some examples that have been posted ( nem's helloword, the wifi example, the httpd example, etc.), we're all doing things a bit differently.
Any thoughts?
Late binding with PSPSDK
Madc,madc wrote:I ported PspPet's code to SDK based. But the synchronization is still a issue. So I haven't call the linked functions from user mode.
Is the work you've done refactoring PspPet's code to be PSPSDK-based posted somewhere for download/viewing? Or are you referring the the sample code which can be pulled from subversion?
Re: Late binding with PSPSDK
Create a seperate stub .s that's has all late imports. Call them libpspfoo_weak.a or something (the plan for kernel libraries was libpspfoo_kernel.a). Put them up somewhere, we'll add them to PSPSDK, and get you svn access.biermana wrote:What is the recommended best practice for late binding (e.g. pspnet libraries) while using the PSPSDK? I could include a startup.s for each project, but based on the example Makefiles that come with the SDK, it would seem the PSPSDK encourages using a "shared" startup.s.
That's the aim of PSPSDK - and to be frank, I think we've superceded nem's stuff and any derivatives quite nicely. If there's something that doesn't suit you in PSPSDK, let us know and submit a patch and we'll work with you to make it better.biermana wrote:I ask this because I feel our community will evolve as we begin to consistently use the same methods/tools/patterns for developing homebrew.
FWIW: I still believe we are missing something obvious here (ie. the patching should be automatic, *in theory*). The first version of the patch code is rather slimy (hard coded addresses etc). Do what you wish with it, but hopefully it will go away if/when we find the right bits to set.
FWIW2: I have a slightly more elegant solution for system traps (ie. like STUB_FUNC but for calling "ForSystem" entries - using direct calls). Great for system hackery (all thanks to the Kernel memory access module flag)
FWIW2: I have a slightly more elegant solution for system traps (ie. like STUB_FUNC but for calling "ForSystem" entries - using direct calls). Great for system hackery (all thanks to the Kernel memory access module flag)