Dumping heap information?
Dumping heap information?
How would I dump heap information on the PSP? And how from there would I be able to act upon the information given to mess with the heaps?
I know I need to use pspsysmem_kernel.h functions to edit the heaps, but the dumping the heaps is the problem, I need a function that can identify the heaps dumped, and return the uid but I can't seem to find one (maybe it has an obscure name?).
Thanks to anyone who helps.
-Aura
I know I need to use pspsysmem_kernel.h functions to edit the heaps, but the dumping the heaps is the problem, I need a function that can identify the heaps dumped, and return the uid but I can't seem to find one (maybe it has an obscure name?).
Thanks to anyone who helps.
-Aura
The only way I know of is to parse the uid tree and pull out the sysmem or heap allocations directly :) Needs kernel mode though and depending what you mean by heap you might not get sensible results ;) i.e. if you are talking about malloc then that has little to do with sysmem other than it allocating a large block to begin with.
Probably sceKernelQueryHeapInfo, which is not in the pspsdk does what you want. I have never used it, but a quick look to the disassembly makes me believe that the usage is like this:
The unknown will have the info about the heap, as I have never used it, don't know which kind of info will have, but probably easy to understand once you dump the data :)
Code: Select all
typedef HeapInfo
{
SceSize size;
u32 unknown[0x3C/4]
} HeapInfo;
HeapInfo heapinfo;
memset(&heapinfo, 0, sizeof(heapinfo));
heapinfo.size = sizeof(heapinfo);
sceKernelQueryHeapInfo(heapuid, &heapinfo);
Hi, thanks for the reply, the heaps I'm refering to are the ones made with sceKernelCreateHeap.
Umm, I'm looking for a function to find me the uid of the heap, this is proving to be the major problem.
Would sceKernelSysMemDumpBlock refer to the heaps, or other memory? I don't have access to a PSP at the moment so I can't test, all I can do is look through the header files.
Oh, and TyRaNiD, I know its likely to have been posted before, but is there any way to get debug output on 3.52 and above?
Thanks again.
-Aura
Umm, I'm looking for a function to find me the uid of the heap, this is proving to be the major problem.
Would sceKernelSysMemDumpBlock refer to the heaps, or other memory? I don't have access to a PSP at the moment so I can't test, all I can do is look through the header files.
Oh, and TyRaNiD, I know its likely to have been posted before, but is there any way to get debug output on 3.52 and above?
Thanks again.
-Aura
No...
If you want to see if it is actually working try this, put some code into a module which does And see if it prints what you expect (i.e. hello) if that works then it is your newlib.
At some point (I can't be bothered to find out the exact revision) sceKernelStdout and sceKernelStderr started returning UID like file descriptors instead of the previous 1 and 2 although those aliases still work in the kernel. It was probably due in part to their fixing up of the file system to make it harder for user apps to fuck it all up. The old fdman code in newlib had an upper bound on the fd which meant that stdout and stderr were not mapped correctly, realistically you could just set them to 1 and 2 anyway, but ...
Blame Sony ;)
If you want to see if it is actually working try this, put some code into a module which does
Code: Select all
sceIoWrite(1, "Hello\n", 6);
At some point (I can't be bothered to find out the exact revision) sceKernelStdout and sceKernelStderr started returning UID like file descriptors instead of the previous 1 and 2 although those aliases still work in the kernel. It was probably due in part to their fixing up of the file system to make it harder for user apps to fuck it all up. The old fdman code in newlib had an upper bound on the fd which meant that stdout and stderr were not mapped correctly, realistically you could just set them to 1 and 2 anyway, but ...
Blame Sony ;)
On my main system, it takes 30-40 minutes to do the entire toolchain. On my old laptop, it takes nearly 3 hours. :)TyRaNiD wrote:You need to get psptoolchain from psp/trunk/psptoolchain and for best results just do a complete rebuild, yes it is painful but hey ;)
Even if you're at the hours end of the spectrum, you don't have to do it very often, so it's not that big a deal. Start the script and go eat dinner.
Hi, I just upgrade my FAT-PSP from 3.40OE to 3.90M2 and in a new PC installed cygwin + toolchain(svn) + psplink(svn)
Everything (psp-g++ and examples) compiled and builded fine, but printf stop working has stopped working on the psp prx's connected to the psplink.
Instead, using sceIoWrite(1, ..) works fine.
I have added the following code to overwrite the printf function and redirect it to the sceIOWrite.
extern "C" {
int printf( const char *msg, ... ) {
char buf[ 1024 ];
va_list ap;
va_start (ap, msg);
int n = vsnprintf (buf, 1023, msg, ap);
va_end (ap);
sceIoWrite( 1, buf, strlen( buf ) );
return n;
}
}
Hope can help somebody
Everything (psp-g++ and examples) compiled and builded fine, but printf stop working has stopped working on the psp prx's connected to the psplink.
Instead, using sceIoWrite(1, ..) works fine.
I have added the following code to overwrite the printf function and redirect it to the sceIOWrite.
extern "C" {
int printf( const char *msg, ... ) {
char buf[ 1024 ];
va_list ap;
va_start (ap, msg);
int n = vsnprintf (buf, 1023, msg, ap);
va_end (ap);
sceIoWrite( 1, buf, strlen( buf ) );
return n;
}
}
Hope can help somebody