Finding the addres of the BSS segment

sandberg · Post by **sandberg** » Thu Jan 12, 2006 5:21 am

Hi,

In my desperate search of figuring out how to get information about the volume level on the PSP I've started to dig into the sceWM8750_Driver module, which is the driver for the audio codec on the PSP. I don't have any experience on assembly on the MIPS platform, so the code basically doesn't say me anything. But I've figured out where the driver stores the information I need for the volume level.

So now I need to know how to figure out where the BSS segment for a prx is located. Using PSPInside, I can see the module info, which is returned by sceKernelQueryModuleInfo. This information lists the two segments (text and data) and the size of these. It also lists the size of the BSS segment, but where is this stored ?

Judgeing from the memory dumps I've studied in PSPInside, it is located right after the data segment, but is this always the case ? If this is normal, I can make a quite simple hack, by querying info from the codec driver and use the information directly. But I'm not much into how a prx and the segments are stored in memory.

Can anyone enlighten me on info about the BSS segment ?

Please :) I've spend quite a lot of time in this quest now, and I'm so close to finish it :)

Post by **TyRaNiD** » Thu Jan 26, 2006 7:55 am

Oki, yes the bss should be after the data always, that is the way the psp allocates its stuff so you should be safe to base your address on the address of the data segment from sceKernelGetModuleInfo.

sandberg · Post by **sandberg** » Thu Jan 26, 2006 8:03 am

Thanks TyRaNiD .. I'll give it a try and see what comes out of it. If it works I'll post the code here, so that others can use it.

Fanjita · Post by **Fanjita** » Fri Jan 27, 2006 1:14 am

If you want to be really paranoid, you could always parse the EBOOT.PBP to find the ELF, then parse its headers to find the definitive info on BSS.

But Tyranid is right, in every PSP ELF I've ever seen (and I've looked at quite a few...) the BSS is right after the data.

sandberg · Post by **sandberg** » Fri Jan 27, 2006 1:25 am

Fanjita wrote:If you want to be really paranoid, you could always parse the EBOOT.PBP to find the ELF, then parse its headers to find the definitive info on BSS.

But Tyranid is right, in every PSP ELF I've ever seen (and I've looked at quite a few...) the BSS is right after the data.

Thanks, but it's not from an eboot, it's from a systems prx, which I need access to its BSS segment. I'll hack some code together tonight to do this.

Fanjita · Post by **Fanjita** » Fri Jan 27, 2006 1:34 am

Oops, sorry, I just noticed that and was about to go back and edit.

Never mind.

sandberg · Post by **sandberg** » Fri Jan 27, 2006 6:19 am

Hi again,

Does any of you have experience with using the sceKernelGetModuleIdList and sceKernelQueryModuleInfo functions ?

I've just tried to do a simple loop to see what it came up with. But it only returns 5 modules ? and when calling sceKernelQueryModuleInfo to get info about these 5 modules it always fails ?

Is there something specific I should know about these functions ? I.e. PSPInside is able to list all loaded modules, so it should somehow be possible.

The code below is run in user mode.

Code: Select all

	int						modulecount;
	int						counter;
	SceUID					modulelist&#91;1024&#93;;
	SceKernelModuleInfo	modinfo;

	if &#40;!sceKernelGetModuleIdList&#40;modulelist, 1024, &modulecount&#41;&#41;
		&#123;
		/* Iterate through all the modules to find the one we're looking for */
		for &#40;counter = 0 ; counter < modulecount ; counter++&#41;
			&#123;
			if&#40;!sceKernelQueryModuleInfo&#40;modulelist&#91;counter&#93;, &modinfo&#41;&#41;
				&#123;
				/* Check if the name matches */
				&#125;
			&#125;
		&#125;

Post by **TyRaNiD** » Fri Jan 27, 2006 6:46 am

Yah, to get the module info you must memset the structure (though probably not really necessary) and then set the size member to the size of the structure, i.e. memset(&modinfo, 0, sizeof(modinfo)); modinfo.size = sizeof(modinfo);

As for why your list is only returning 5 modules I am not sure, there could be permission issues but I am assuming you are running in kernel mode otherwise you will not be able to access the kernel module stuff.

You are not by chance running on a v1 are you? If you are then GetModuleIdList isn't support, and QueryModuleInfo doesn't actually work ;) THere are equivalent functions in the sdk library (libpspsdk.a) which do the same thing on v1 firmware.

Fanjita · Post by **Fanjita** » Fri Jan 27, 2006 7:22 am

If you're trying to run on v2.0 then you need to be careful about which functions you're using, as Tyranid says.

You will also find that you don't get full details back for most of the modules - not many modules, plus virtually no information about most of them, are hallmarks of running these functions in user mode.

For reference, the usable ones from user mode are sceKernelGetModuleIdList and sceKernelQueryModuleInfo - so it sounds like you are using the right ones.

Remember also to check the parameters you're passing to GetModuleIdList, the 'readbufSize' parameter is in bytes rather than longs, if I remember rightly - so you might inadvertently be passing a value that's smaller than you intend, which can limit the results you get.

sandberg · Post by **sandberg** » Fri Jan 27, 2006 7:53 am

Thanks guys.

Running it in kernel mode (it ran in user mode before) and setting the size of the structure did the trick, and gave me a list of 68 modules, where the audio codec is one of them.

But I guess after all that this is not the best way to do it :) .. It most likely wouldn't work on 2.0 either. So I guess I have to figure out how to use the UART which is used for communication with the audio codec.

But thanks a lot for your help, I got to learn a lot figuring all this out.