Bug in psploadcore.h ?

[LEROY]

Hi everyboady.

I'm just wondering is there is a (small) bug in psploadcore.h / sceModule definition.

Here is an extract of my code

Code: Select all

	SceUID ids[512];
	memset(ids, 0, 512 * sizeof(SceUID));

	result = sceKernelGetModuleIdList(ids, 512 * sizeof(SceUID), &count);
	if&#40;result < 0&#41; return result;

	for&#40;p = 0; p < count; p++&#41;
	&#123;
		SceModule* mod = sceKernelFindModuleByUID&#40;ids&#91;p&#93;&#41;;
		if&#40;mod&#41;
		&#123;
			pspDebugScreenSetTextColor&#40;0x000000FF&#41;;
			fdprintf&#40;log_fd, "sceModule #%3d , @ %p, %s\n", p, mod, mod->modname&#41;;
			pspDebugScreenSetTextColor&#40;0x0000FF00&#41;;
			fdprintf&#40;log_fd, "\tnext &#58; %p\n", mod->next&#41;;
			fdprintf&#40;log_fd, "\tattribute &#58; %04X\n", mod->attribute&#41;;
			fdprintf&#40;log_fd, "\tversion %02X/%02X\n", mod->version&#91;0&#93;, mod->version&#91;1&#93;&#41;;
			fdprintf&#40;log_fd, "\tmodname &#58; %s\n", mod->modname&#41;;
			fdprintf&#40;log_fd, "\tterminal %2X\n", mod->terminal&#41;;
			fdprintf&#40;log_fd, "\tmodid &#58; %#010X\n", mod->modid&#41;;
			fdprintf&#40;log_fd, "\tent_top &#58; %p\n", mod->ent_top&#41;;
			fdprintf&#40;log_fd, "\tent_size &#58; %d\n", mod->ent_size&#41;;
			fdprintf&#40;log_fd, "\tstub_top &#58; %p\n", mod->stub_top&#41;;
			fdprintf&#40;log_fd, "\tstub_size &#58; %d\n", mod->stub_size&#41;;
			fdprintf&#40;log_fd, "\tentry_addr &#58; %#010X\n", mod->entry_addr&#41;;
			fdprintf&#40;log_fd, "\tgp_value &#58; %#010X\n", mod->gp_value&#41;;
			fdprintf&#40;log_fd, "\ttext_addr &#58; %#010X\n", mod->text_addr&#41;;
			fdprintf&#40;log_fd, "\ttext_size &#58; %#010X\n", mod->text_size&#41;;
			fdprintf&#40;log_fd, "\tdata_size &#58; %#010X\n", mod->data_size&#41;;
			fdprintf&#40;log_fd, "\tbss_size &#58; %#010X\n", mod->bss_size&#41;;
			fdprintf&#40;log_fd, "\tnsegment &#58; %#010X\n", mod->nsegment&#41;;
...

And here is the result

• sceModule # 0 , @ 88011794, sceSystemMemoryManager
  next : 8801169c
  attribute : 1007
  version 02/01
  modname : sceSystemMemoryManager
  terminal 0
  modid : 0X0022EF33
  ent_top : 8800d474
  ent_size : 112
  stub_top : 8800d4ec
  stub_size : 0
  entry_addr : 0XFFFFFFFF
  gp_value : 0X8800B6A8
  text_addr : 0X88017860
  text_size : 0X88000000
  data_size : 0X0000F338
  bss_size : 0X0000052C
  nsegment : 0X000005A8
  segmentaddr[0] : 0X00000002
  segmentsize[0] : 0000000000
  segmentaddr[1] : 0X88000000
  segmentsize[1] : 0X0000F340
  segmentaddr[2] : 0X8800F340
  segmentsize[2] : 0X0000052C
  segmentaddr[3] : 0000000000
  segmentsize[3] : 0000000000
  segmentaddr[4] : 0000000000
  segmentsize[4] : 0000000000

Rather strange, isn't it ? Looks like there is a 4 bytes shift somewhere. Looking at sceModule definition in psploadcore.h

Code: Select all

/** Describes a module.  This structure could change in future firmware revisions. */
typedef struct SceModule {
        struct SceModule        *next;
        unsigned short          attribute;
        unsigned char           version[2];
        char                            modname[27];
        char                            terminal;
        unsigned int            unknown1;
        unsigned int            unknown2;
        SceUID                          modid;
        unsigned int            unknown3[4];
        void *                          ent_top;
        unsigned int            ent_size;
        void *                          stub_top;
        unsigned int            stub_size;
        unsigned int            unknown4[4];
        unsigned int            entry_addr;
        unsigned int            gp_value;
        unsigned int            text_addr;
        unsigned int            text_size;
        unsigned int            data_size;
        unsigned int            bss_size;
        unsigned int            nsegment;
        unsigned int            segmentaddr[4];
        unsigned int            segmentsize[4];
} SceModule;

If I change unsigned int unknown4[4] to unknown4[5], I get a definitely better result.

• sceModule # 0 , @ 88011794, sceSystemMemoryManager
  next : 8801169c
  attribute : 1007
  version 02/01
  modname : sceSystemMemoryManager
  terminal 0
  modid : 0X0022EF33
  ent_top : 8800d474
  ent_size : 112
  stub_top : 8800d4ec
  stub_size : 0
  entry_addr : 0X8800B6A8
  gp_value : 0X88017860
  text_addr : 0X88000000
  text_size : 0X0000F338
  data_size : 0X0000052C
  bss_size : 0X000005A8
  nsegment : 0X00000002
  segmentaddr[0] : 0X88000000
  segmentsize[0] : 0X0000F340
  segmentaddr[1] : 0X8800F340
  segmentsize[1] : 0X0000052C

Sounds like something is wrong in psploadcore or am I missing something ?

Thanks

LEROY

[jimparis]

Yes, you are missing the

Code: Select all

This structure could change in future firmware revisions.

comment. :) What firmware are you using? See SceKernelThreadKInfo for an example of adding firmware-dependent fields.

[LEROY]

Yes, you are missing the

Code: Select all

This structure could change in future firmware revisions.

comment. :) What firmware are you using? See SceKernelThreadKInfo for an example of adding firmware-dependent fields.

You're right, I just missed that part :P

I'm on 1.5.

Thanks for the advice. I'll check SceKernelThreadKInfo.

LEROY

[jimparis]

If you're on 1.5, it might just be a bug in the header.
Anyone else come across this before?

[TyRaNiD]

That header was actually determined in the 1.0 era and has not changed since. Normally it isn't a good idea to use it other than to map names/addresses etc to a UID (as the modid field doesn't seem to have ever moved in location). You can then use the UID to determine the information you want through the published API.

As with alot of the internal kernel structures they are there because at some point someone worked out the structure, it is questionable whether it is really important to track them in every firmware version as even with the FW versioning in the SDK you are still limited by the fact that once it is built it is static.