Support ps4sh transition

[hitodama]

• Antonio should be supported in his efforts to adapt the sdk
• Fork -> Pull request asap.

[psxdev]

ps4link stuff compiled and run fine with ps4sdk

There is not elfloader.c and elfloader.h so i included both in my test inside libps4link/source and libps4link/include

You made some changes (again :P) in memoryprotect stuff changes needed done in commands.c and elfloader.h

Also changes in my Makefiles to adapt to ps4sdk

it was a little messy to include libraries needed to compile and order is important to avoid undefined errors

but finally all compiled an tested fine running ps4ftp from ps4sh so
ps4link is ps4sdk compliant

I need to commit changes to ps4link not ready yet and perhaps we need some documentation for final user first to compile samples with new ps4sdk

[hitodama]

Hi :) Thanks, for trying and looking into it! :)
I think we should wait until v0.1.0 is done too. Maybe when we are there we should commit the move to the sdk by hosting it on ps4dev together with the release and docs :)!

PS: I laughed at the memory.h comment :D I am so sorry. I tried this time to follow Sony as close as possible. They break their rules with libkernel (naming is all non-object oriented) but most often then try to do: Namespace(Namespace)MainobjectVerb(Resultobject). So I added "Get" etc. I had a terrible time doing this ^^' because I argue with myself: "Is it Kernel.Hook.Function or Kernel.Function.Hook" ^^' Every few days I rename in circles :P

[hitodama]

Uh, you should look at / try ps4KernelCall! :)
It has default and variable arguments. ps4KernelCall(fn, args...) works for all non long double functions up to 6 args (it will be more complicated to add xmm).

[psxdev]

i have created a branch in ps4link with changes to get all running with ps4sdk
https://github.com/psxdev/ps4link/tree/ps4sdk_work

What is the best form to add libraries in samples(chek them in my new branch)?

libSceNet_stub is not added in makefiles by default and i need to add my libs also. I don't like to use LinkerFlags:
Makefile for samples:

ifndef Ps4Sdk
ifdef ps4sdk
Ps4Sdk := $(ps4sdk)
endif
ifdef PS4SDK
Ps4Sdk := $(PS4SDK)
endif
ifndef Ps4Sdk
$(error Neither PS4SDK, Ps4Sdk nor ps4sdk set)
endif
endif

target ?= ps4_elf
TargetFile= payload.elf

include $(Ps4Sdk)/make/ps4sdk.mk
LinkerFlags+=-ldebugnet -lSceNet_stub

Would be better to modify ps4_untargeted.mk to accept for example libraries(or whatever name we choose) variable and add them to Libraries?

What do you think?

[hitodama]

Hey!
I agree, we should have an all inclusive target.

"Untargeted" will produce a bit of different assembler, because it knows the architecture better (optimizations too). Overall it's not needed.
I suggest branching "untargeted" adding in what is in "ps4" (sce flags) and creating different "ps4-" targets as we need them.

"All" would be a good target. But we should (eventually) supply at least two extra variables to support changing:

• The exploit (LibraryKernelExecute ?)
• The Syscall (LibraryAssemblerSyscall ?)
  So that individual make files can easily set them (maybe then even should be required to set them? This way everybody who writes a program knows what it targets?) Otherwise you get the effect "This does not build the right thing / run anymore" because we altered the default to a new firmware or so.

If you like to change the way the current Make system works, I am sure you come up with something good. Adding libs dynamically should be easily supported (Library += foo.a) or so, so that we can add in stuff like the elfloader.a as needed and so that we can create more libs (comple other ppls code) outside the sdk.

PS: Good that you try to avoid using linker flags! :)
I am not a build system (Make) guru. If you like to rewrite most of the build system, its Ok - I would probably like it ^^'