Code Instrumentation

[71M]

Has anyone successfully used the gcc -finstrument-functions compile flag to instrument PSP code?

Cheers,
71M

[mrbrown]

There is currently no library support for any of GCC's profiling or instrumentation options.

[71M]

Ok, thanks. Shame really as it'd be really useful for debugging.

Cheers,
71M

[RustyFunkNut]

And for profiling :)

[HoldAndModify]

Hi, just wondering if -pg is supported now? I tried this and received undefined reference to _mcount when building a sample program with this.

If I am doing something wrong, help would be appreciated. Assuming this works, would the profile info be written to some gmon.out on the mem stick?

Thanks...

[mrbrown]

Nope, _mcount isn't defined anywhere. While it would be trivial to add support for counting how many times functions are called, I can't figure out a sane way to do PC sampling with the PSP's OS.

[crazyc]

Nope, _mcount isn't defined anywhere. While it would be trivial to add support for counting how many times functions are called, I can't figure out a sane way to do PC sampling with the PSP's OS.

Do alarms not interrupt execution, do they not have high enough resolution or is there no way to get the previously running thread PC?

[HoldAndModify]

Nope, _mcount isn't defined anywhere. While it would be trivial to add support for counting how many times functions are called, I can't figure out a sane way to do PC sampling with the PSP's OS.

Hmm...well, if you'd like to summarize your investigations in this area, I'd be happy to investigate further.

Proper gprof support would probably really help all emu authors optimize things.

Cheers,
HAM

[mrbrown]

Do alarms not interrupt execution, do they not have high enough resolution or is there no way to get the previously running thread PC?

Right, I couldn't figure out how to get the PC of the current thread. The stupid thread status struct gives you everything except that. I didn't see an easy way to sample the PC in kernel mode either.

Hrm... ok, just had a thought. How about saving the caller's return address in _mcount(), and "sampling" that in an alarm handler? It wouldn't be a precise PC sample but it would at least tell you where all your time was being spent. Of course the other problem with that method is that there's no way to figure out if all your time is being spent in the kernel or in some other PRX.

[crazyc]

Hrm... ok, just had a thought. How about saving the caller's return address in _mcount(), and "sampling" that in an alarm handler? It wouldn't be a precise PC sample but it would at least tell you where all your time was being spent. Of course the other problem with that method is that there's no way to figure out if all your time is being spent in the kernel or in some other PRX.

Wouldn't it be possible to wrap each kernel entry stub with a function to call mcount? That at least would tell you how much time is being spent in the kernel.