Very rarely (maybe 1/30 app launches), strange behavior occurs in the PS4's rtld (runtime linker) which causes it to spam kernel log with obj_get_str: offset is out of range of string table errors.

If you let it run it's course, it leaks a bunch of memory and after a few seconds the system will panic when a kmem_alloc call fails due to kmem_map being too small.

If you exit the application before it gets to that point, you'll crash due to a bad unlink, presumably meaning even if the system doesn't run out of memory, memory corruption occurs on an important linked list.

This issue doesn't seem to be Mira-specific, but I also don't see how it could be an issue from toolchain-built ELFs because parsing bugs are deterministic. If an eboot is malformed, it should crash the loader in the same way every time. This could be an issue that's in the overlapped codebase shared among HEN implementations, including vortex's HEN and Miras.

I've opened it here for now as I'm not 100% certain it's a Mira bug / where this corruption is coming from.

<68> EXEC /app0/eboot.bin [user], vm#1, dmem#1  <290263 msec>
D/99301:Sysmodule:
libSceFios2.sprx is loaded from the development machine system.
[rtld] <68> ERROR obj_get_str:6802: offset=27 is out of range of string table of /app0/eboot.bin.
[rtld] <68> ERROR obj_get_str:6802: offset=27 is out of range of string table of /app0/eboot.biD/99301:Sysmodule:
libc.sprx is loaded from the development machine system.
n.
[rtld] <68> ERROR obj_get_str:6802: offset=27 is out of range of string table of /app0/eboot.bin.
[rtld] <68> ERROR obj_get_str:6802: offset=27 is out of range of string table of /app0/eboot.bin.
...
panic: kmem_malloc(1789526016): kmem_map too small: 37961728 total allocated
cpuid = 7

Exceptions are also currently disabled for the libcxx build. Try to support them for v1.0 stable.

In linux, sockaddr_in's structure definition is:

struct sockaddr_in {
    sa_family_t    sin_family; /* address family: AF_INET */
    in_port_t      sin_port;   /* port in network byte order */
    struct in_addr sin_addr;   /* internet address */
};

In FreeBSD, sockaddr_in's structure definition is:

struct sockaddr_in {
    uint8_t	sin_len;
    sa_family_t	sin_family;
    in_port_t	sin_port;
    struct	in_addr sin_addr;
    char	sin_zero[8];
};

This discrepancy will cause issues when calling syscalls such as bind(). This issue will need to be fixed in the output header sys/netinet/in.h from musl.

Currently it's possible for functions defined locally to get written to the NID table. This happens if a defined function matches the same name as one that exists in a linked in module. What lead to this discovery was MUSL having function names like inet_pton which overlap with functions found in the libkernel module.

A fix has been worked on but needs to be tested and shipped.

The build script for the visual studio "OpenOrbis SPRX Project" template contains bad defaults which will lead to re-linking errors in create-lib. This is because the template tries to link against libc instead of libSceLibcInternal. This bug/regression was caused by the switch to musl and wasn't caught.

This is currently being done by Lord Friky.

A few people have tested and with VS2019 (possibly other versions?), they've reported unknown type name '__va_list' errors in the stdio.h. header.

Tried to compile a first homebrew (hello world) and I have created the bin file with success with VS2019
But then I started the app on PS4 and I got a black screen.
Do I need Mira Hen to run it? Do I need VS2017 and not the 2019 version?
Thanks

We should have documentation / wiki pages for known PS4 library functions and their arguments. This will be an on-going process.

Currently threading is disabled in the libcxx build, as work needs to be done to wrap std::thread around the scePthread subsystem. This is more something that would be nice to have but probably isn't a rush, std::thread doesn't seem to be a popular component of stdlib anyway.

The Linux signature of pipe() is int pipe(int fds[2]). However, on FreeBSD the signature is essentially int[2] pipe(void), and the file descriptors are returned in RDX:RAX.

This is pretty necessary for the purpose of creating a shared library to begin with. 😄

Currently projects are "Makefile projects" because standard VS projects do a lot of weird things internally that cause issues with using the non-MS clang. At some point it'd be nice to have full VS integration.

This does not take into account the padding bytes of the procParamSection.

Correct calculation would be something like:
dataSize := (dataSection.Offset - procParamSection.Offset) + dataSection.Size

In order to have a compliant libc (with sce variable modifications sceHeapSize) newlib needs to be stabilized. Currently newlib builds for the ps4 target, but 0 of the elf-loaders aren't ghetto enough to actually load a proper ELF.

Currently debugging information like symbols is not carried over from the ELF to the Orbis ELF (OELF) intermediate file. This isn't too bad because the ELF file is still kept and can be referenced, but it would be nice to have debugging info carried over, negating the need to use the ELF file.

The library template default code includes a header:

#include "libexample.h"

However this header's name in the project is "libExample.h". In practice this doesn't break compilation but the compiler does complain and give a warning due to the incorrect case.

I have made some changes (which I believe are improvements) to the hello_world Makefile. For example:

• set the clang flag -isysroot to the SDK root,
• use the flag -isystem for system includes,
• use the x86_64-scei-ps4-elf target, and create orbis-ld wrapper script that appends SDK-specific linker arguments,
• generate gp4 file and param.sfo automatically.

I posted the Makefile as a gist at: https://gist.github.com/john-tornblom/b63467bd56ea8758c99a51d7b9ccdb78
the files create-gp4 and orbis-ld needs to be placed in $OO_PS4_TOOLCHAIN/bin/linux for the Makefile to work correctly.

MiraLib is mostly done but needs to be converted to .NET core for CI.

It records a size one byte less than it should be.

We need to port libcxx for support for stdlib for C++.

I have tried to build and install the hello world sample on my ps4 using the linux v0.2 SDK, but when I start the example, I get an error message complaining about corruption. I get the same behavior when installing the hello world pkg file present in the linux v0.2 SDK release zip. I'm using the HEN payload distributed by ps4gentoo, do I need some other specific payload to actually launch homebrew produced by openorbis?

Related: OpenOrbis/musl#4

We're going to attempt to transition Mira away from the Workaround8849 and ioctl hook for homebrew as it breaks a lot of games. Because the loader requires sce_module/libc.prx and sce_module/libSceFios2.prx and we cannot redistribute the real ones, we'll have dummy libraries that don't do anything since homebrew doesn't use these libraries anyway. Libc is static linked in, and fios2 contains exotic functions that (at least currently) aren't used. In the future, the fios2 stub can be updated to support functionality once reversed.

On larger binaries (such as the SDL sample), the create-eboot tool has some serious performance issues, to the point where the SDL sample takes 15 seconds. This is extremely annoying as part of the build process.

After profiling, it seems the issue is due to unnecessary complexity in the GenerateLibrarySymbolDictionary() function

pprof reports:

(pprof) list checkIfLibraryContainsSymbol
Total: 14.39s
ROUTINE ======================== main.checkIfLibraryContainsSymbol in /home/specter/openorbis/OpenOrbis-PS4-Toolchain/src/tools/create-eboot/Utils.go
      10ms     13.07s (flat, cum) 90.83% of Total
         .          .     84:
         .          .     85:// checkIfLibraryContainsSymbol takes a given library and symbol name, and checks if the library contains that symbol. It
         .          .     86:// returns a boolean of whether or not that library contains that symbol, as well as error. If we cannot get a libraries
         .          .     87:// symbol list, false and an error is returned. Otherwise, the true or false and nil are returned.
         .          .     88:func checkIfLibraryContainsSymbol(library *elf.File, symbolName string) (bool, error) {
         .     12.98s     89:	if librarySymbols, err := library.Symbols(); err == nil {
      10ms       80ms     90:		for _, sym := range librarySymbols {
         .       10ms     91:			if sym.Name == symbolName {
         .          .     92:				return true, nil
         .          .     93:			}
         .          .     94:		}
         .          .     95:	} else {
         .          .     96:		return false, err

The issue is we invoke library.Symbols() on every symbol, which adds unnecessary complexity. What should happen here is the library symbols should be cached into a map, then the symbol should be checked against said map.

pkg.gp4 files bundled with the samples use Windows-style relative paths (i.e. sce_sys\icon0.png). This causes package creation to fail on non-Windows systems.

The makefiles for samples currently don't create the intermediate directory before building, so "no such file or directory" errors occur unless you make the dir in advance.

Meant to get to this before the toolchain dropped but it slipped through the cracks.

create-pkg tool is described in the README.md but is missing from the repository, as well as the release tarball.

C++ specific crap like .ctors, .dtors, interfaces, and other features are not currently supported in create-eboot/create-lib. We'll wanna add these to eventually fully support C++.

It would be nice to have an SDL library and sample as it'll help with homebrew dev.

Currently features (even under feature level C++14), mutex, lock_guard, and other locking features are not implemented yet

When writing to the std::cout output stream, after one operand passes through the << operator, the badbit and failbit is set on the stream and no further operands are processed. For example, if you compile:

#include <iostream>

int main()
{
    std::cout << "Test 1 " << "Test 2" << std::endl;
    return 0;
}

Your output would look like this:

Test 1 

"Test 2" doesn't make it to stdout. I discovered ultimately the failbit gets set by the ostream's __put_character_sequence template when calling __pad_and_output().

src

template<class _CharT, class _Traits>
basic_ostream<_CharT, _Traits>&
__put_character_sequence(basic_ostream<_CharT, _Traits>& __os,
                          const _CharT* __str, size_t __len)
{
#ifndef _LIBCPP_NO_EXCEPTIONS
    try
    {
#endif  // _LIBCPP_NO_EXCEPTIONS
        typename basic_ostream<_CharT, _Traits>::sentry __s(__os);
        if (__s)
        {
            typedef ostreambuf_iterator<_CharT, _Traits> _Ip;
            if (__pad_and_output(_Ip(__os),
                                 __str,
                                 (__os.flags() & ios_base::adjustfield) == ios_base::left ?
                                     __str + __len :
                                     __str,
                                 __str + __len,
                                 __os,
                                 __os.fill()).failed())
                __os.setstate(ios_base::badbit | ios_base::failbit); // <---- Specter: badbit and failbit are set here
        }
#ifndef _LIBCPP_NO_EXCEPTIONS
    }
    catch (...)
    {
        __os.__set_badbit_and_consider_rethrow();
    }
#endif  // _LIBCPP_NO_EXCEPTIONS
    return __os;
}

What's odd is ostream is used by a lot of other streams, std::stringstream and std::ofstream for instance, however these two work fine, it's only std::cout specifically that has an issue.

Currently samples use a logging class which functions similar to std::cout, but this is hacky, and fixing cout directly would be ideal if possible. Help would be greatly appreciated here as the libcxx codebase is complex and my previous attempts at root causing this have been unsuccessful.

Currently there is no way to call functions that we have nids for but no names for. There is a fix/workaround for this, but currently isn't supported. Eventually add support for this.

Current text rendering is rough around the edges because of the draw function erroneously not factoring in the greyscale bitmap to blend with the background. The SDL sample has a fixed text rendering function but it needs to be brought over to the common one for other samples as well.

We should probably put libraries on Continuous Integration (CI) that way any updates can be pulled immediately from the artifacts without having to wait for them to be bundled in a release.

AF_INET6 is 28 on both stock FreeBSD and PS4, but is erroneously set to 10 in the OpenOrbis headers. There may be other similar errors.

Although the build directory is named as "Debug", the Makefile does not specify the -g compiler flag, which results in the binaries being built without debug_info.

A fix is to add -g to CFLAGS and LFLAGS inside each Makefile.

The zip compression format does not preserve file permissions very well. Consider using tar.gz files instead, or use Info-Zip, which would simplify the installation on POSIX-based systems.

For more information on the issue, see https://stackoverflow.com/questions/10735297/maintain-file-and-folder-permissions-inside-archives

using ::signbit;
using ::fpclassify;
using ::isfinite;
using ::isinf;
using ::isnan;
using ::isnormal;
using ::isgreater;
using ::isgreaterequal;
using ::isless;
using ::islessequal;
using ::islessgreater;
using ::isunordered;
using ::isunordered;

These functions are not implemented and making flatbuffers fail.

We'd like bindings provided for MiraLib to use in C, C++, Python, and Rust. The python binding is being tackled by myself, however help is welcome for the other bindings once the MiraLib Core (#15) goes up.

• C
• C++
• Python
• Rust

Please consider including PkgTool.Core with the linux SDK. This enables full automation of making pkg files on linux using the following makefile target:

TITLE      := My Homebrew
VERSION    := 1.00
TITLE_ID   := BREW00001
CONTENT_ID := IV0000-BREW00001_00-MYHOMEBREW000000

sce_sys/param.sfo:
	PkgTool.Core sfo_new $@
	PkgTool.Core sfo_setentry $@ APP_TYPE --type Integer --maxsize 4 --value 1 
	PkgTool.Core sfo_setentry $@ APP_VER --type Utf8 --maxsize 8 --value '$(VERSION)'
	PkgTool.Core sfo_setentry $@ ATTRIBUTE --type Integer --maxsize 4 --value 0  
	PkgTool.Core sfo_setentry $@ CATEGORY --type Utf8 --maxsize 4 --value 'gd'  
	PkgTool.Core sfo_setentry $@ CONTENT_ID --type Utf8 --maxsize 48 --value '$(CONTENT_ID)'
	PkgTool.Core sfo_setentry $@ DOWNLOAD_DATA_SIZE --type Integer --maxsize 4 --value 0 
	PkgTool.Core sfo_setentry $@ SYSTEM_VER --type Integer --maxsize 4 --value 0  
	PkgTool.Core sfo_setentry $@ TITLE --type Utf8 --maxsize 128 --value '$(TITLE)'
	PkgTool.Core sfo_setentry $@ TITLE_ID --type Utf8 --maxsize 12 --value '$(TITLE_ID)'
	PkgTool.Core sfo_setentry $@ VERSION --type Utf8 --maxsize 8 --value '$(VERSION)'

Bleeding-edge binaries are published at
https://ci.appveyor.com/project/maxton/liborbispkg/build/artifacts

The setup-project.sh and setup-toolchain.sh scripts in /extra use CRLF line endings instead of LF endings, which causes errors when running the scripts.

maxton has corrected the issue causing bad packages files to be made.

maxton/LibOrbisPkg@e17db36

Buffering should just be disabled on stdout due to buffering not being handled well. All the samples disable buffering via setvbuf, but we may as well make it so you don't have to do this to get all the data sent to stdout.

Moving issue from previous repo. In progress.

Some samples only really do useful stuff through the kernel log, which doesn't make it super obvious what's actually happening. There are also some graphic-related samples that could use some adjustments.

With C++ support, also rework some samples to utilize C++.

• Font sample rewrite
• Graphics sample rewrite
• Hello world sample rewrite
• Input sample rewrite
• PNG decoding sample rewrite
• System sample rewrite
• Threading sample rewrite

Add a changelog containing changes from alpha as well as changes going forward.

Currently creating releases is a pain and involves some manual work. Simplify this by creating a script to do it. We'll also move away from NSIS as the installer is lacking in features.

• Release script
• New installer

As per study, We need to write a driver for gnm commands if we want to be able to fully use gnm for 3d graphics.

Bigboss(psxdev) has made some progress on this and when this toolchain is public, i'll assign him to this issue.

• CrazyVoid