SceModule struct - bug in sdk?

[kralyk]

Hi,
I think there's either a bug in SceModule structure definition, or I missed something critical...

the structure is here: http://dark-alex.org/pspsdk_docs/structSceModule.html
I made a simple dump from what sceKernelFindModuleByName returned and this is what I got:
(it's vshControl module)

Code: Select all

E4 3E 22 88 07 10 03 01 56 73 68 43 6F 6E 74 72 6F 6C 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 05 04 00 00 3A 00 01 00 4B 43 48 04 
FF FF FF FF 4D 9A 48 04 01 00 00 00 01 00 00 00 10 BF 24 88 20 00 00 00 
38 BF 24 88 04 01 00 00 3C A0 24 88 FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF<- 3C A0 24 88 00 4B 25 88 00 80 24 88 F8 42 00 00 3C 02 00 00 
20 02 00 00 01 00 00 00 00 80 24 88 00 00 00 00 00 00 00 00 00 00 00 00 
30 4D 00 00 00 00 00 00 00 00 00 00 

Acording to the structure as it is in sdk, the SceModule->entry_addr contains 0xFFFFFFFF (marked by <- in code) which really doesnt seem like a valid pointer.

from what I figured out while reversing some modules that use this struct, the unknown4 member should be 5 ints long, not 4.
So entry_addr is the next int and text_addr is int number 27.
If you look at text_size, it makes sense...

I have checked this by dereferencing text_addr+4 and comparing the result to disassembly and it fits.

What do you think?

[cory1492]

Are you working on 1.50 firm based files (which is what a large chunk of the sdk is based on, thus it shouldn't be a bug)? If so the struct should be accurate. If not 150 or lower look for more recent m33 sdk in 4.01m33, it has SceModule2 defined in it for use with 1.50+ modules

Code: Select all

// from 4.01m33 sdk
// For 1.50+

typedef struct SceModule2 
{
	struct SceModule	*next; // 0
	u16					attribute; // 4
	u8					version[2]; // 6
	char				modname[27]; // 8
	char				terminal; // 0x23
	char				mod_state;	// 0x24
    char				unk1;    // 0x25
	char				unk2[2]; // 0x26
	u32					unk3;	// 0x28
	SceUID				modid; // 0x2C
	u32					unk4; // 0x30
	SceUID				mem_id; // 0x34
	u32					mpid_text;	// 0x38
	u32					mpid_data; // 0x3C
	void *				ent_top; // 0x40
	unsigned int		ent_size; // 0x44
	void *				stub_top; // 0x48
	u32					stub_size; // 0x4C
	u32					entry_addr_; // 0x50
	u32					unk5[4]; // 0x54
	u32					entry_addr; // 0x64
	u32					gp_value; // 0x68
	u32					text_addr; // 0x6C
	u32					text_size; // 0x70
	u32					data_size;	// 0x74
	u32					bss_size; // 0x78
	u32					nsegment; // 0x7C
	u32					segmentaddr[4]; // 0x80
	u32					segmentsize[4]; // 0x90
} SceModule2;

[kralyk]

right, I didnt know about that, thanks... is there a docu for m33 sdk at all?
And shouldn't the new struct be copied over to pspsdk as well?
Some people don't use m33 sdk... (I dont use it when I dont have to)

oh and no, I work on 5.00 modules...

[Torch]

All those online docs are severely outdated. Checkout the latest SDK from the SVN and use Doxygen yourself to generate the HTML documentation. You can use Doxygen on the M33SDK to generate its documentation too.

[Davee]

Code: Select all

typedef struct SceModule
{
	struct SceModule*	next; //0, 0x00
	u16 				attribute; //4, 0x04
	u8 					version[2]; //6, 0x06
	char 				modname[27]; //8, 0x08
	char 				terminal; //35, 0x23
	u16 				status; //36, 0x24 (Used in modulemgr for stage identification)
	u16 				padding; //38, 0x26
	u32 				unk_28; //40, 0x28
	SceUID 				modid; //44, 0x2C
	SceUID 				usermod_thid; //48, 0x30
	SceUID 				memid; //52, 0x34
	SceUID 				mpidtext; //56, 0x38
	SceUID 				mpiddata; //60, 0x3C
	void *				ent_top; //64, 0x40
	u32 				ent_size; //68, 0x44
	void *				stub_top; //72, 0x48
	u32 				stub_size; //76, 0x4C
	int 				(* module_start)(SceSize, void *); //80, 0x50
	int 				(* module_stop)(SceSize, void *); //84, 0x54
	int 				(* module_bootstart)(SceSize, void *); //88, 0x58
	int 				(* module_reboot_before)(void *); //92, 0x5C
	int 				(* module_reboot_phase)(SceSize, void *); //96, 0x60
	u32 				entry_addr; //100, 0x64(seems to be used as a default address)
	u32 				gp_value; //104, 0x68
	u32 				text_addr; //108, 0x6C
	u32 				text_size; //112, 0x70
	u32 				data_size; //116, 0x74
	u32 				bss_size; //120, 0x78
	u8 					nsegment; //124, 0x7C
	u8					padding[3]; //125, 0x7D
	u32 				segmentaddr[4]; //128, 0x80
	u32 				segmentsize[4]; //144, 0x90
	int 				module_start_thread_priority; //160, 0xA0
	SceSize 			module_start_thread_stacksize; //164, 0xA4
	SceUInt 			module_start_thread_attr; //168, 0xA8
	int 				module_stop_thread_priority; //172, 0xAC
	SceSize 			module_stop_thread_stacksize; //176, 0xB0
	SceUInt 			module_stop_thread_attr; //180, 0xB4
	int 				module_reboot_before_thread_priority; //184, 0xB8
	SceSize 			module_reboot_before_thread_stacksize; //188, 0xBC
	SceUInt 			module_reboot_before_thread_attr; //192, 0xC0
} SceModule;

That is the correct SceModule structure.