relibc issueshttps://gitlab.redox-os.org/redox-os/relibc/-/issues2024-03-26T16:24:46Zhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/192Implement posix_spawn2024-03-26T16:24:46ZJacob Lorentzon4ldo2@protonmail.comImplement posix_spawnSince Redox's `execv*` and `fork` implementations are based on the lower-level kernel context handles, it would be preferable to provide a custom implementation of `posix_spawn{,p}`, using those native APIs. The API in `redox-exec` alrea...Since Redox's `execv*` and `fork` implementations are based on the lower-level kernel context handles, it would be preferable to provide a custom implementation of `posix_spawn{,p}`, using those native APIs. The API in `redox-exec` already supports executing a remote process, which could be combined with the fork API, minus the copy-everything-and-then-reinitialize-everything parts.https://gitlab.redox-os.org/redox-os/relibc/-/issues/191aarch64 float compile errors2024-02-21T00:44:20ZRon Williamsaarch64 float compile errorsA dev reported the following while compiling gettext.
```plaintext
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(.text+0x10e8): ...A dev reported the following while compiling gettext.
```plaintext
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(.text+0x10e8): undefined reference
to *
addtf3'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasnprintf.c:(text+0x10f4): undefined reference
to ' fixtfsi'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasprintf.c:(text+0x1100): undefined reference
to *
floatunsitf'
~/redox/prefix/aarch64-unknown-redox/relibc-install/bin/../lib/gcc/aarch64-unknown
- redox/13.2.0/../../../../aarch64-unknown-redox/bin/ld: vasprintf.c:(.text+0x110c): undefined reference
to :
subtf3'
.....
```https://gitlab.redox-os.org/redox-os/relibc/-/issues/190Use a different format for passing argv/envp/auxv in execv2024-03-26T16:20:34ZJacob Lorentzon4ldo2@protonmail.comUse a different format for passing argv/envp/auxv in execvCurrently, Redox's execve implementation emulates Linux's format for passing the argv and envp pointers, and the auxiliary vectors, but this has several downsides. The current implementation does lots of mmap calls, which although it cou...Currently, Redox's execve implementation emulates Linux's format for passing the argv and envp pointers, and the auxiliary vectors, but this has several downsides. The current implementation does lots of mmap calls, which although it could be improved anyway, would be significantly easier with a simpler format. It also currently requires Redox-specific auxiliary vectors, which are passed null-terminated, which is true for envp too. The sigprocmask and "sigignmask" (POSIX requires execve to remember which signals were ignored, but otherwise reset them), as well as some internal relibc fds, would likely also need a custom auxv.
A simpler format would instead pass a header struct, providing the values the mandatory auxvs would otherwise provide, which might look like the following:
```rust
struct Header {
args_base: *const u8,
args_len: usize,
envs_base: *const u8,
envs_len: usize,
stack_top: *const u8,
stack_len: usize,
cwd_base: *const u8,
cwd_len: usize,
phnum: u16,
phentsize: u16,
page_size: u32,
phdr: u64,
procmask: u64, // set to "all blocked" until overridden by this value
ignmask: u64, // set to "all SIG_DFL" or "all SIG_IGN" until overridden by this value
interp_header: *const Header, // nullable
hwcap: u64,
}
```
It might also be possible for the args and envs to not be NUL-terminated, since relibc is forced to copy them anyway.https://gitlab.redox-os.org/redox-os/relibc/-/issues/189getgrgid array of pointers error etc.2024-02-04T20:16:16ZRon Williamsgetgrgid array of pointers error etc.`gr_mem` should be a pointer to an array of pointers, where each entry is the address of a string. Currently, it is a pointer to the buffer containing the strings. Some thought needs to be given to how the array of pointers is allocated....`gr_mem` should be a pointer to an array of pointers, where each entry is the address of a string. Currently, it is a pointer to the buffer containing the strings. Some thought needs to be given to how the array of pointers is allocated.
https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/header/grp/mod.rs?ref_type=heads#L133
`parse_group` has two variables named `buf`, it looks like there is an attempt to use both the current meaning and the previous meaning.
https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/header/grp/mod.rs?ref_type=heads#L190
The code that opens `/etc/groups` is duplicated many times, maybe put it in a function?Jacob SchneiderJacob Schneiderhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/188[Feature Request]Ignore negative fd in poll(2)2024-03-26T16:21:12ZSteve Lau[Feature Request]Ignore negative fd in poll(2)Requested by [nix-rust/nix#2254](https://github.com/nix-rust/nix/issues/2254), I would like to have `poll(2)` ignore the `pollfd`s that have a negative file descriptor
This is not specified in the POSIX spec, but almost all the OSes hav...Requested by [nix-rust/nix#2254](https://github.com/nix-rust/nix/issues/2254), I would like to have `poll(2)` ignore the `pollfd`s that have a negative file descriptor
This is not specified in the POSIX spec, but almost all the OSes have this feature implemented:
| OS | Supported |
|---------|------------|
|darwin |Yes|
| linux |Yes|
|android |Probably yes|
| freebsd |Yes|
|dragonfly|Yes|
|netbsd |Yes|
|openbsd |Yes|
|illumos |Yes|
|solaris |Yes|
|haiku |Yes|
|redox |No|https://gitlab.redox-os.org/redox-os/relibc/-/issues/187Once openat is supported on Redox, consider using dirfds for `/` and for the cwd2023-12-24T22:28:54ZJacob Lorentzon4ldo2@protonmail.comOnce openat is supported on Redox, consider using dirfds for `/` and for the cwdOnce openat is supported, I think there should be a statically allocated fd number used for cwd. This means getcwd <=> realpath(__get_cwd_fd), chdir(path) <=> dup2(__get_cwd_fd, tmp := open(path)) then close(tmp), fchdir(fd) <=> dup2(__g...Once openat is supported, I think there should be a statically allocated fd number used for cwd. This means getcwd <=> realpath(__get_cwd_fd), chdir(path) <=> dup2(__get_cwd_fd, tmp := open(path)) then close(tmp), fchdir(fd) <=> dup2(__get_cwd_fd, fd). Since chdir is async-signal-safe, it currently needs to do two sigprocmasks for every open(), but using dup2 to replace the file description the fd points to, is already fully atomic.
If openat eventually replaces regular open, relibc might also store a statically allocated fd for /, making chroot trivial. The only problem is that fpath probably needs to continue to exist, but openat could take a "dirfd is root" flag so fpath returns a path relative to that root.https://gitlab.redox-os.org/redox-os/relibc/-/issues/186is_traceme performance issue2023-12-23T10:29:53ZRon Williamsis_traceme performance issueis_traceme is being called very frequently, and each call calls `File::open`, creating a performance problem.
Someone should determine if this is correct behavior, it seems like there should be additional guards around this.is_traceme is being called very frequently, and each call calls `File::open`, creating a performance problem.
Someone should determine if this is correct behavior, it seems like there should be additional guards around this.https://gitlab.redox-os.org/redox-os/relibc/-/issues/185Add configuration instructions for Linux on the README2023-11-03T09:39:34ZRibbonAdd configuration instructions for Linux on the READMEWe need to document how to replace glibc with relibc on the build systems.
Goals:
- [ ] Add a Cargo example
- [ ] Add a Makefile example
- [ ] Add a CMake example
- [ ] Add a Meson exampleWe need to document how to replace glibc with relibc on the build systems.
Goals:
- [ ] Add a Cargo example
- [ ] Add a Makefile example
- [ ] Add a CMake example
- [ ] Add a Meson examplehttps://gitlab.redox-os.org/redox-os/relibc/-/issues/184Tracking issue for missing functions to compile CPython 3.122023-10-22T23:45:53ZDarley BarretoTracking issue for missing functions to compile CPython 3.12- [ ] bindtextdomain
- [ ] bind_textdomain_codeset
- [ ] clock_nanosleep
- [ ] close_range
- [ ] confstr
- [ ] copy_file_range
- [ ] ctermid
- [ ] __ctype_b_loc
- [ ] __ctype_tolower_loc
- [ ] __ctype_toupper_loc
- [ ] dcgettext
- [ ] du...- [ ] bindtextdomain
- [ ] bind_textdomain_codeset
- [ ] clock_nanosleep
- [ ] close_range
- [ ] confstr
- [ ] copy_file_range
- [ ] ctermid
- [ ] __ctype_b_loc
- [ ] __ctype_tolower_loc
- [ ] __ctype_toupper_loc
- [ ] dcgettext
- [ ] dup3
- [ ] eventfd
- [ ] eventfd_read
- [ ] eventfd_write
- [ ] faccessat
- [ ] fchmodat
- [ ] fchownat
- [ ] fcntl64
- [ ] fdopendir
- [ ] fexecve
- [ ] fgetxattr
- [ ] flistxattr
- [ ] fopen64
- [ ] forkpty
- [ ] fremovexattr
- [ ] fsetxattr
- [ ] fstat64
- [ ] fstatat64
- [ ] fstatvfs64
- [ ] ftruncate64
- [ ] getloadavg
- [ ] getresgid
- [ ] getresuid
- [ ] getrlimit64
- [ ] getrusage
- [ ] getxattr
- [ ] initgroups
- [ ] lgetxattr
- [ ] __libc_current_sigrtmax
- [ ] __libc_current_sigrtmin
- [ ] __libc_start_main
- [ ] linkat
- [ ] listxattr
- [ ] llistxattr
- [ ] lockf64
- [ ] login_tty
- [ ] lremovexattr
- [ ] lseek64
- [ ] lsetxattr
- [ ] lstat64
- [ ] memfd_create
- [ ] mkdirat
- [ ] mkfifoat
- [ ] mknod
- [ ] mknodat
- [ ] mmap64
- [ ] nice
- [ ] nl_langinfo
- [ ] open64
- [ ] openat64
- [ ] openpty
- [ ] pause
- [ ] posix_fadvise64
- [ ] posix_fallocate64
- [ ] posix_spawn
- [ ] posix_spawnattr_destroy
- [ ] posix_spawnattr_init
- [ ] posix_spawnattr_setflags
- [ ] posix_spawnattr_setpgroup
- [ ] posix_spawnattr_setschedparam
- [ ] posix_spawnattr_setschedpolicy
- [ ] posix_spawnattr_setsigdefault
- [ ] posix_spawnattr_setsigmask
- [ ] posix_spawn_file_actions_addclose
- [ ] posix_spawn_file_actions_adddup2
- [ ] posix_spawn_file_actions_addopen
- [ ] posix_spawn_file_actions_destroy
- [ ] posix_spawn_file_actions_init
- [ ] posix_spawnp
- [ ] pread64
- [ ] preadv64v2
- [ ] pwrite64
- [ ] pwritev64v2
- [ ] readdir64
- [ ] readlinkat
- [ ] removexattr
- [ ] renameat
- [ ] __sched_cpualloc
- [ ] __sched_cpucount
- [ ] __sched_cpufree
- [ ] sched_getaffinity
- [ ] sched_getparam
- [ ] sched_get_priority_max
- [ ] sched_get_priority_min
- [ ] sched_getscheduler
- [ ] sched_rr_get_interval
- [ ] sched_setaffinity
- [ ] sched_setparam
- [ ] sched_setscheduler
- [ ] sem_clockwait
- [ ] sendfile64
- [ ] setegid
- [ ] seteuid
- [ ] setns
- [ ] setresgid
- [ ] setresuid
- [ ] setrlimit64
- [ ] setxattr
- [ ] sigwaitinfo
- [ ] splice
- [ ] stat64
- [ ] statvfs64
- [ ] symlinkat
- [ ] syscall
- [ ] __sysconf
- [ ] textdomain
- [ ] times
- [ ] truncate64
- [ ] __uflow
- [ ] unlinkat
- [ ] unshare
- [ ] utimensat
- [ ] wait3
- [ ] wait4
- [ ] waitid
- [ ] wcsftime
- [ ] wcsxfrmhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/182printf swallowed when unknown format specifiers are encountered2023-08-14T17:51:59ZFlorian Meißnerprintf swallowed when unknown format specifiers are encountered```c
#include <stdio.h>
int main(void) {
int foobar = 0;
printf("%Y", foobar);
return 0;
}
```
glibc Output: `%Y`
relibc Output: nothing```c
#include <stdio.h>
int main(void) {
int foobar = 0;
printf("%Y", foobar);
return 0;
}
```
glibc Output: `%Y`
relibc Output: nothinghttps://gitlab.redox-os.org/redox-os/relibc/-/issues/181Not all memory is reclaimed when pthreads are destroyed2023-08-02T12:47:40ZJacob Lorentzon4ldo2@protonmail.comNot all memory is reclaimed when pthreads are destroyedMost notably, the stack is not freed in pthread_join or the implicit possibly-later-called pthread_detach destructor. The TCB doesn't appear to be either.
[This branch](https://gitlab.redox-os.org/4lDO2/relibc/-/commits/fix_memleak) fix...Most notably, the stack is not freed in pthread_join or the implicit possibly-later-called pthread_detach destructor. The TCB doesn't appear to be either.
[This branch](https://gitlab.redox-os.org/4lDO2/relibc/-/commits/fix_memleak) fixes part of it, but it seems like there are leaks elsewhere too.https://gitlab.redox-os.org/redox-os/relibc/-/issues/178Rustify2024-01-12T17:50:49ZRibbonRustifyThis issue covers the relibc parts that benefit from using a Rustier implementation, in order to be less prone to memory unsafety and to some extent logic bugs.
- [ ] [Rusty error handling](https://gitlab.redox-os.org/redox-os/relibc/-/...This issue covers the relibc parts that benefit from using a Rustier implementation, in order to be less prone to memory unsafety and to some extent logic bugs.
- [ ] [Rusty error handling](https://gitlab.redox-os.org/redox-os/relibc/-/issues/176)
- [ ] [Rust's libm port](https://gitlab.redox-os.org/redox-os/relibc/-/issues/154)
- [x] dlmallochttps://gitlab.redox-os.org/redox-os/relibc/-/issues/176Rusty error handling2023-11-12T15:41:15ZJacob Lorentzon4ldo2@protonmail.comRusty error handlingCurrently, relibc primarily does C-like error handling (returning -1 and setting errno). A better alternative would be to use `Result<T, Errno>`, which AFAIK currently only the inner pthread implementation does. If `Errno` is defined as ...Currently, relibc primarily does C-like error handling (returning -1 and setting errno). A better alternative would be to use `Result<T, Errno>`, which AFAIK currently only the inner pthread implementation does. If `Errno` is defined as `NonZeroU32`, then the common "zero for success or -1 with errno" can be represented zero-cost as `Result<(), Errno>`. Only the outer C functions would convert the inner OS-abstracted platform functions into "-1 and errno", or other types of error handling (such as pthread's "0 or error code").
Worth noting both Redox and Linux represent syscall errors as negative error numbers (in Linux's case, between -4096 and -1, and currently in Redox's case, all negative numbers), so this change would most likely not lead to performance degradation.https://gitlab.redox-os.org/redox-os/relibc/-/issues/174Use corresponding syscalls for {p,}{read,write}{v,}2024-03-26T16:19:51ZJacob Lorentzon4ldo2@protonmail.comUse corresponding syscalls for {p,}{read,write}{v,}Currently, only read and write, out of read/pread/readv/preadv/preadv2 and write/pwrite/writev/pwritev/pwritev2, are part of the platform abstraction trait. On Linux, adding missing syscall wrappers for this would be relatively easy, and...Currently, only read and write, out of read/pread/readv/preadv/preadv2 and write/pwrite/writev/pwritev/pwritev2, are part of the platform abstraction trait. On Linux, adding missing syscall wrappers for this would be relatively easy, and Redox will likely get support for them soon (only preadv2 and pwritev2 as they are the superset of all the other ones).https://gitlab.redox-os.org/redox-os/relibc/-/issues/173Tracking issue for missing POSIX APIs2024-03-26T16:14:44ZJacob Lorentzon4ldo2@protonmail.comTracking issue for missing POSIX APIsWhile Redox's aim is not full POSIX compatibility, there are lots of missing APIs that generally only come with benefits.
Non-exhaustive list:
- [x] `wcsrtombs` (https://gitlab.redox-os.org/redox-os/relibc/-/issues/166)
- [x] `UTIME_OM...While Redox's aim is not full POSIX compatibility, there are lots of missing APIs that generally only come with benefits.
Non-exhaustive list:
- [x] `wcsrtombs` (https://gitlab.redox-os.org/redox-os/relibc/-/issues/166)
- [x] `UTIME_OMIT` and `UTIME_NOW` (https://gitlab.redox-os.org/redox-os/relibc/-/issues/172)
- [ ] `wait3` (no longer in POSIX?, https://gitlab.redox-os.org/redox-os/relibc/-/issues/170)
- [ ] `malloc.h` (not in POSIX?, https://gitlab.redox-os.org/redox-os/relibc/-/issues/136)
- [x] `towctrans` and `wctrans` (https://gitlab.redox-os.org/redox-os/relibc/-/issues/32)
- [ ] some `sys/mman.h` defs (https://gitlab.redox-os.org/redox-os/relibc/-/issues/73)
- [x] some networking constants (https://gitlab.redox-os.org/redox-os/relibc/-/issues/164)
- [ ] `mknod` (https://gitlab.redox-os.org/redox-os/relibc/-/issues/103)
- [x] `swprintf`
- [ ] `swscanf`
- [x] `ungetwc`
- [x] `vfwprintf`
- [x] `vwprintf`
- [x] `vswprintf`
- [ ] `wcsftime`
- [ ] `wcswcs`
- [ ] `wcsxfrm`
- [x] `wprintf`
- [ ] `wscanf`
Not all POSIX APIs are available as stubs, but those that are, can be found by looking for commented-out `#[no_mangle]`, e.g. via `rg '^.*//.*#\[no_mangle\]'`.
There are some POSIX requirements that will be much harder to fix. First, the current context=process=thread assumption must be dealt with. Second, POSIX appears to allow all characters but NUL and '/', which conflicts with how schemes work (even returning an error due to lack of support for : in the filesystem, doesn't apply, as it will work but the behavior will be different).
### Implementation
Almost all POSIX functions are well-documented on https://pubs.opengroup.org. Another good reference is [cppreference.com](https://en.cppreference.com/w/c).https://gitlab.redox-os.org/redox-os/relibc/-/issues/171Lack of error handling before TLS is initialized2023-06-03T12:38:22ZJacob Lorentzon4ldo2@protonmail.comLack of error handling before TLS is initialized`errno` is currently defined as a thread-local, and this makes all functions using `errno` completely fault-intolerant when TLS has not yet been initialized, which is the case when mapping the TLS memory itself, and in (most of) ld.so. A...`errno` is currently defined as a thread-local, and this makes all functions using `errno` completely fault-intolerant when TLS has not yet been initialized, which is the case when mapping the TLS memory itself, and in (most of) ld.so. Any failure will thus cause a SIGSEGV, and while it may not make sense to handle errors while e.g. allocating the TCB or memory for loading dynamic programs, it should at least *be possible* to handle the errors. The best solution is probably to lower the use of errno to the C-facing API, away from the platform trait which is used internally. (We could also define `errno` as a macro, like `#define errno (*errno_location())`, and use TLS only after a flag has been set, even though TLS will have been initialized before user code starts, and we don't use C macros much inside relibc.)https://gitlab.redox-os.org/redox-os/relibc/-/issues/170wait4/wait3 support2024-01-06T23:56:29ZLuca Barbatowait4/wait3 supportRecently I started to look into ways to get the resource information reliably and ~~`wait4()`~~/`wait3()` seem to work better than `getrusage()`. Does redox have a similar facility to leverage?Recently I started to look into ways to get the resource information reliably and ~~`wait4()`~~/`wait3()` seem to work better than `getrusage()`. Does redox have a similar facility to leverage?https://gitlab.redox-os.org/redox-os/relibc/-/issues/167Reduce dependencies by replacing goblin with object2023-02-26T11:17:02ZYonggang LuoReduce dependencies by replacing goblin with objectHow about using object instead goblin in relibc, as in rust runtime, the backtrace component already using object instead goblin because of it's less dependencies.How about using object instead goblin in relibc, as in rust runtime, the backtrace component already using object instead goblin because of it's less dependencies.https://gitlab.redox-os.org/redox-os/relibc/-/issues/163relibc can't be used to generate dynamically linked -fno-pie executables2020-06-24T10:08:42ZAhmed Abd El Mawgoodrelibc can't be used to generate dynamically linked -fno-pie executablesrelibc ld.so is statically linked no-pie binary, it is loaded at 0x40000. That address is the default loading address for any no-pie binary. So If we have a binary that gets loaded at 0x40000 as well it gets conflicted with relibc ld.so....relibc ld.so is statically linked no-pie binary, it is loaded at 0x40000. That address is the default loading address for any no-pie binary. So If we have a binary that gets loaded at 0x40000 as well it gets conflicted with relibc ld.so. As such one would need to have static-pie ld.so The problem with that is that to the best of my knowledge rustc doesn't support static-pie targets as of yet.https://gitlab.redox-os.org/redox-os/relibc/-/issues/162How to test ld.so2020-05-08T20:42:17ZAhmed Abd El MawgoodHow to test ld.sold.so is getting complex by the day, and I can't figure a proper way for unit testing or adding regression tests for ld.so. I might need help with that.ld.so is getting complex by the day, and I can't figure a proper way for unit testing or adding regression tests for ld.so. I might need help with that.