Added db for 3.65/3.67

[TheOfficialFloW]

We need to have a way to specify 3.65/3.67 NIDs. Maybe use *_367_stub.a?

[CelesteBlue-dev]

Have the NIDs of 3.60 functions changed on 3.65/3.67 or are there only some new functions ?
EDIT: from studying 3.65 kernel modules I've understood that:

• when some function name doesn't change but it's function NID changes, the library NID changes,
• when NID of a library changes, usually all the functions NIDs of the library change,
  I haven't seen new functions yet.

[xerpi]

An improved proposal based on yours:
Let's imagine foo_stub.a exports the function bar.
By using weak symbols we make foo_368_stub.a export bar as a weak symbol alias and export bar_368 regularly.
So if you link with both foo_stub.a and foo_368_stub.a, calling bar will call the regular version, and bar_368 will call the foo_368_stub.a one.
If you link only with foo_368_stub.a, barwill be aliased to bar_368.

[CelesteBlue-dev]

@xerpi do you mean you are proposing to call ksceMemcpy_368(); when compiling for 3.68 ?

[xerpi]

@CelesteBlue-dev that would be necessary only if you want to call the 368 version of ksceMemcpy and you are linking with both stubs.
If you only link with *_368_stub.a, thanks to the alias, calling ksceMemcpy would also be possible.

[CelesteBlue-dev]

@xerpi I think the easiest way is to edit vita-elf-create or such to add --version argument.
When -v 368, it will link sceMemcpy_stub_368.a.
By default, to keep compatibility, when version is not specified it will link 360 stubs.

[xerpi]

@CelesteBlue-dev but you don't even need to touch vita-elf-create for that, only your Makefile.

[CelesteBlue-dev]

yes but with my way, you would only have to do make 368 or make 365 or make (by default 360).
Now I see what you mean :

if (is_368())
     func_368()
else
     func()

but so which libs do you import ? 360 stubs or 368 stubs ?

[xerpi]

My 'way' isn't different than yours but only an improvement that also allows you to be able to choose what function to call at runtime.

[CelesteBlue-dev]

@xerpi sorry I don't understand how a skprx can be loaded if it imports 368 and 360 stubs.
it will forcibly return SCE_KERNEL_ERROR_NO_LIB...

[xerpi]

Hmm so if an SKPRX imports an invalid library it returns an error when loading it? I thought it would just leave the stubs uninitialized.

[TheOfficialFloW]

I don't think it will work either, since you'll end up with two libraries with the same name but different library nid. Maybe it works if we declare it as weak import, can somebody test?

[CelesteBlue-dev]

@xerpi I tried loading a skprx that imported 360 NIDs on my 365 PSVita using your kernel loader and it returns an error :
SCE_KERNEL_ERROR_MODULEMGR_NO_LIB | 0x8002d003 | C1-2712-2
or
SCE_KERNEL_ERROR_MODULEMGR_OLD_LIB | 0x8002d013 | C1-2728-9
or maybe also :
SCE_KERNEL_ERROR_MODULEMGR_INVALID_LIB | 0x8002d009 | C1-2718-8
SCE_KERNEL_ERROR_MODULEMGR_INVALID_STUB | 0x8002d00a | C1-2719-9
SCE_KERNEL_ERROR_MODULEMGR_NO_FUNC_NID | 0x8002d00b | C1-2720-1
SCE_KERNEL_ERROR_MODULEMGR_NO_VAR_NID | 0x8002d00c | C1-2721-2
EDIT : it was NOT weak imports. So try weak, it may work as theflow says.

[xerpi]

Yeah maybe weak imports might do the trick. My thought was that the Vita's dynamic loader would skip unknown libraries intead of erroring.

[d3m3vilurr]

replaced #592