Hey guys,
I am running 3.80 - m33 CFW with 1.5 kernel addon, all apps, every single one that i've downloaded run perfectly.
My problem is this,
If I wrote a simple program that uses file io functions such as,
sceIoOpen/Close/Read/Write ...
THe wierd thing is when i compile my program WITHOUT: BUILD_PRX = 1
and run the EBOOT.PBP from the pspsh (in psplink) it runs just fine.
However when i compile it WITH: BUILD_PRX = 1
if i run the <app>.prx or EBOOT.PBP
it chokes with no error or anything... psplink just acts like it is ok
however if i try to type anything in pspsh, such as, reset or anything else
it just hangs...
THis is driving me insane,
I have tried debugging and the only thing I can see is that, the <app>.prx chokes on the sceIoXXXX functions.
Here's the debugger output, hope it helps you help me:
GDB is unable to find the start of the function at 0x88140f4
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x88140f4 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
warning: GDB can't find the start of the function at 0x88140f3.
0x088140f4 in ?? ()
PSPLINK adventures
a .PRX module doesn't take all the memory by default (a .PRX module being to a .DLL or .SO module in PC world, it doesn't make a sense for it to take all the memory). By adding the macro PSP_HEAP_SIZE_MAX(), you allow this .PRX module to do so which is not a problem because it happens to be run as the main executable and not as a single dynamic library. I guess stack is allocated at the end of the heap, so its size may naturally varied. I don't know for sure about how a .PRX module creates and handles its stack as I suppose it is just a collection of functions to be called by another executable (so those functions should run in the stack of the executable, not in their module stack if any).binaryONE wrote:Oh ! nice man, fixed it.
Thanks.
Is there some heap-size difference between firmwares now?