openorbis / musl Goto Github PK

Do you think it will be possible to run https://openjdk.java.net/projects/portola on the PS4?

In Linux, musl is received as a light libc variant, and alternative to glibc. Over the years/decades, glibc has gathered bulk due to backwards compatibility support, which musl shaves off, and generally developers of musl libc make choices to keep the code size small (it's almost 1/3^rd of the size of glibc).

Given the above, I have few questions:

1. Does FreeBSD's libc also suffer with same "bulkiness" issue as glibc, such that it makes observable difference when it was replaced by musl?
2. Do you see a potential in upstreamming patches to musl?
3. Do you see a potential in proposing a change to FreeBSD to make building the OS with musl (instead of FreeBSD's in-tree libc) optional?

Got this while trying to compile JamVM:

ld.lld: error: undefined symbol: _pthread_cleanup_push
>>> referenced by res_msend.c
>>>               res_msend.lo:(__res_msend_rc) in archive /home/sergey/openorbis//lib/libc.a

ld.lld: error: undefined symbol: _pthread_cleanup_pop
>>> referenced by res_msend.c
>>>               res_msend.lo:(__res_msend_rc) in archive /home/sergey/openorbis//lib/libc.a

Musl is internally using some pthread functions (pthread_cleanup_push and pthread_cleanup_pop in this case) that are not implemented in the "fallback" implementation.

Originally reported by LM in the discord:

Apparently sleep() does not function properly, calling it is effectively a no-op.

The socket options for Linux and BSD use different values for, e.g., SO_REUSEADDR, which in turn cause setsockopt to behave incorrectly.

musl: #define SO_REUSEADDR 2
freebsd: #define SO_REUSEADDR 0x0004

For syscalls that the PS4 doesn't have available, we currently punt by always returning -1. There seems to be two broad categories for how we can usually do this better, though:

1. Syscalls that really have no equivalent at all, like fanotify_init, should set errno to ENOSYS, so that the caller will have a clue about why it actually failed, instead of getting a random unrelated error.
2. Syscalls that can be emulated in userspace with only slight degradation, like pipe2, should do that instead of failing entirely. In fact, in that case it looks like the code to do that is already there; we just #ifdef'ed out a bit too much.

This is not a bugreport, just a possible enhancement.

Arguments:

1. Issuing syscalls directly requires a patched kernel. If some other way of running homebrew (e.g. a code execution vulnerability in a JIT-enabled system app) approaches, OpenOrbis toolchain would be of no use.
2. It seems that libkernel explicitly omits some syscall wrappers. Sony can expect that replacing one of those with another custom syscall won't break existing code.
3. Little can be done without loading system libraries, and those depend on libkernel anyway.
4. libkernel wrappers are supposed to be C functions, so using them could allow to avoid low-level ABI incompatibilities.

In file included from src/fcntl/open.c:2:
src/fcntl/open.c: In function 'open':
src/fcntl/open.c:16:21: warning: 'mode_t' {aka 'short unsigned int'} is promoted to 'int' when passed through '...'
   16 |   mode = va_arg(ap, mode_t);
./include/stdarg.h:14:44: note: in definition of macro 'va_arg'
   14 | #define va_arg(v,l)     __builtin_va_arg(v,l)
      |                                            ^
src/fcntl/open.c:16:21: note: (so you should pass 'int' not 'mode_t' {aka 'short unsigned int'} to 'va_arg')
   16 |   mode = va_arg(ap, mode_t);
./include/stdarg.h:14:44: note: in definition of macro 'va_arg'
   14 | #define va_arg(v,l)     __builtin_va_arg(v,l)
      |                                            ^
src/fcntl/open.c:16:21: note: if this code is reached, the program will abort
   16 |   mode = va_arg(ap, mode_t);
./include/stdarg.h:14:44: note: in definition of macro 'va_arg'
   14 | #define va_arg(v,l)     __builtin_va_arg(v,l)
      |                                            ^

XXX: is this actually an upstream issue?