redox-os issueshttps://gitlab.redox-os.org/groups/redox-os/-/issues2019-06-18T20:17:04Zhttps://gitlab.redox-os.org/redox-os/handbook/-/issues/1Targeted audience2019-06-18T20:17:04ZJeremy SollerTargeted audience*Created by: k0pernicus*
Nice project :-)
Just a question: is the targeted audience of this book is geek users/common OS developers, or Rust developers?
Just to know if we have to talk about Rust code, give examples, etc...?
*Created by: k0pernicus*
Nice project :-)
Just a question: is the targeted audience of this book is geek users/common OS developers, or Rust developers?
Just to know if we have to talk about Rust code, give examples, etc...?
https://gitlab.redox-os.org/redox-os/binutils-gdb/-/issues/3--update-section issue updating section s_addr2023-09-08T17:54:38ZJeremy Soller--update-section issue updating section s_addr*Created by: mikedefrancis*
I am using --update-section to patch the contents of linux elf files.
Section s_addr addresses are not updated after modifying sections that come before. Program still executes, but section ram mapping is ...*Created by: mikedefrancis*
I am using --update-section to patch the contents of linux elf files.
Section s_addr addresses are not updated after modifying sections that come before. Program still executes, but section ram mapping is no longer accurately represented in the elf linker view.
When I use --update-section to append additional code to the .init and .text sections, the program header addresses and sizes are updated correctly for the program to load, and the section header sizes and file offsets are updated correctly. The problem is that the section s_addr field is not updated correctly, causing my disassembler to become very confused.
![image](https://user-images.githubusercontent.com/9902708/31101855-7708ad4a-a79d-11e7-8f18-86b41efca775.png)
https://gitlab.redox-os.org/redox-os/newlib/-/issues/80Implement link and chown2019-01-12T13:36:30ZJeremy SollerImplement link and chown*Created by: xTibor*
The kernel now has [`link`](https://github.com/redox-os/syscall/blob/7dc00e7ea4162f8886412d936f14ea5b7d834d41/src/call.rs#L220) and [`fchown`](https://github.com/redox-os/syscall/blob/7dc00e7ea4162f8886412d936f14ea5...*Created by: xTibor*
The kernel now has [`link`](https://github.com/redox-os/syscall/blob/7dc00e7ea4162f8886412d936f14ea5b7d834d41/src/call.rs#L220) and [`fchown`](https://github.com/redox-os/syscall/blob/7dc00e7ea4162f8886412d936f14ea5b7d834d41/src/call.rs#L93) syscalls to implement it. I made some attempts to do it but couldn't get newlib to build on my machine.https://gitlab.redox-os.org/redox-os/newlib/-/issues/82Cannot compile newlib on arch2023-09-24T10:03:08ZJeremy SollerCannot compile newlib on arch*Created by: laerus*
using the `makepkg -si` according to [docs](https://doc.redox-os.org/book/getting_started/installing_the_toolchain.html)
```
error[E0522]: definition of an unknown language item: `oom`
--> src/lib.rs:188:1
|...*Created by: laerus*
using the `makepkg -si` according to [docs](https://doc.redox-os.org/book/getting_started/installing_the_toolchain.html)
```
error[E0522]: definition of an unknown language item: `oom`
--> src/lib.rs:188:1
|
188 | #[lang = "oom"]
| ^^^^^^^^^^^^^^^ definition of unknown language item `oom`
```
```
active toolchain
----------------
nightly-x86_64-unknown-linux-gnu
rustc 1.28.0-nightly (952f344cd 2018-05-18)
```https://gitlab.redox-os.org/redox-os/newlib/-/issues/78Build failure on arch2019-01-12T13:36:30ZJeremy SollerBuild failure on arch*Created by: anxiousmodernman*
Rust: rustc 1.25.0-nightly (15a1e2844 2018-01-20)
Following the for building worked up until this point.
```
# Then newlib
cd ../newlib
makepkg -si
```
The first thing I notice is a rust compi...*Created by: anxiousmodernman*
Rust: rustc 1.25.0-nightly (15a1e2844 2018-01-20)
Following the for building worked up until this point.
```
# Then newlib
cd ../newlib
makepkg -si
```
The first thing I notice is a rust compiler error
![redox](https://user-images.githubusercontent.com/396004/35190756-4851bc8a-fe1e-11e7-81ed-711ce1aca563.png)
Then, things proceed, and makepkg finally terminates here:
![untilhere](https://user-images.githubusercontent.com/396004/35190759-5fe56c02-fe1e-11e7-9908-b7675c77c223.png)
https://gitlab.redox-os.org/redox-os/newlib/-/issues/66Licensing2023-09-24T10:03:02ZIan Douglas ScottLicensingNewlib contains a mix of licenses, which is awkward.... anyway, the Redox code does not have a clear license. It should probably be marked as MIT licensed (with permission from contributors).Newlib contains a mix of licenses, which is awkward.... anyway, the Redox code does not have a clear license. It should probably be marked as MIT licensed (with permission from contributors).https://gitlab.redox-os.org/redox-os/newlib/-/issues/58Implement more termios functions2023-09-24T10:03:05ZJeremy SollerImplement more termios functionsImplement stubs left from https://github.com/redox-os/newlib/pull/57Implement stubs left from https://github.com/redox-os/newlib/pull/57https://gitlab.redox-os.org/redox-os/relibc/-/issues/113Update the repository description.2018-06-24T20:16:50ZJeremy SollerUpdate the repository description.*Created by: 0x0f0f0f*
Today I searched for `standard library language:rust` on GitHub.
Nothing about relibc was listed.
The description could be updated to something like `C Standard Library replacement written in Rust for Redox and ...*Created by: 0x0f0f0f*
Today I searched for `standard library language:rust` on GitHub.
Nothing about relibc was listed.
The description could be updated to something like `C Standard Library replacement written in Rust for Redox and Linux` to get it listed in more search results and attract new github users.https://gitlab.redox-os.org/redox-os/relibc/-/issues/125stdout is not buffered when using printf()2018-10-07T13:40:42ZJeremy Sollerstdout is not buffered when using printf()*Created by: Arcterus*
As far as I can tell, it seems that `printf()` just dumps out the string to `stdout` without buffering, which is what caused the slowness I noticed when testing `qsort()`.*Created by: Arcterus*
As far as I can tell, it seems that `printf()` just dumps out the string to `stdout` without buffering, which is what caused the slowness I noticed when testing `qsort()`.https://gitlab.redox-os.org/redox-os/relibc/-/issues/107Add Windows & bare-metal support.2018-07-13T18:59:40ZJeremy SollerAdd Windows & bare-metal support.*Created by: lygstate*
*Created by: lygstate*
https://gitlab.redox-os.org/redox-os/relibc/-/issues/106Use this math.2018-06-24T20:08:20ZJeremy SollerUse this math.*Created by: lygstate*
https://github.com/japaric/m*Created by: lygstate*
https://github.com/japaric/mhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/99socket: Implement the standard socket functions2020-02-12T22:57:29ZDan Robertsonsocket: Implement the standard socket functionsImplement the standard socket functions. The standard socket functions are currently stubbed in `src/socket/src/lib.rs`.
- [ ] `socket`
- [ ] `connect`
- [ ] `bind`
- [ ] `accept`
- [ ] `listen`
- [ ] `recv`
- [ ] `recvfr...Implement the standard socket functions. The standard socket functions are currently stubbed in `src/socket/src/lib.rs`.
- [ ] `socket`
- [ ] `connect`
- [ ] `bind`
- [ ] `accept`
- [ ] `listen`
- [ ] `recv`
- [ ] `recvfrom`
- [ ] `send`
- [ ] `sendto`
A good reference on a previous implementation of the RedoxOS platform specific version of these functions can be found in `src/todo/oldlib/socket.rs`.
https://gitlab.redox-os.org/redox-os/relibc/-/issues/93Safe vs Unsafe in library functions.2018-07-13T18:59:40ZJeremy SollerSafe vs Unsafe in library functions.*Created by: Tommoa*
Currently, almost all implemented library functions are marked as `unsafe`. Should we be aiming to make as many library functions "safe" (or as close to, we still need to work with raw pointers) as possible, or shou...*Created by: Tommoa*
Currently, almost all implemented library functions are marked as `unsafe`. Should we be aiming to make as many library functions "safe" (or as close to, we still need to work with raw pointers) as possible, or should everything just be left as `unsafe`?https://gitlab.redox-os.org/redox-os/relibc/-/issues/89Incorrect return type2018-07-13T18:59:40ZJeremy SollerIncorrect return type*Created by: tdbgamer*
https://github.com/redox-os/relibc/blob/d75535974ae37e7d698c01c46584705b790e0bc9/src/string/src/lib.rs#L277
I believe this function is supposed to return `size_t`. Actually it looks like all the functions in th...*Created by: tdbgamer*
https://github.com/redox-os/relibc/blob/d75535974ae37e7d698c01c46584705b790e0bc9/src/string/src/lib.rs#L277
I believe this function is supposed to return `size_t`. Actually it looks like all the functions in that file that return `c_ulong` should return `size_t`. I modified the type and the tests passed fine for me. Should I open a PR?https://gitlab.redox-os.org/redox-os/relibc/-/issues/88signal: Implement kill and killpg2018-07-13T18:59:40ZDan Robertsonsignal: Implement kill and killpg[kill] and [killpg] have not been implemented yet. The implementation should be fairly straightforward as both Linux and RedoxOS have syscalls for `kill`.
- [x] `kill`
- [x] `killpg`
The implementation of other function such a...[kill] and [killpg] have not been implemented yet. The implementation should be fairly straightforward as both Linux and RedoxOS have syscalls for `kill`.
- [x] `kill`
- [x] `killpg`
The implementation of other function such as `read` could be helpful as a reference. See the platform generic implementation of `read` [here](https://github.com/redox-os/relibc/blob/3890ec58f0fbf792b213c9fec722fee5a4a796a2/src/unistd/src/lib.rs#L326-L331) and the platform specific implementations in `platform` for [linux](https://github.com/redox-os/relibc/blob/3890ec58f0fbf792b213c9fec722fee5a4a796a2/src/platform/src/linux/mod.rs#L138-L140) and [redox](https://github.com/redox-os/relibc/blob/3890ec58f0fbf792b213c9fec722fee5a4a796a2/src/platform/src/redox/mod.rs#L179-L181) for an example of how this can be done.
[kill]: http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html
[killpg]: http://pubs.opengroup.org/onlinepubs/009695399/functions/killpg.htmlhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/87unistd: Implement getopt2018-07-13T18:59:40ZDan Robertsonunistd: Implement getoptThe current implementation of [getopt] (in [src/unistd/src/lib.rs]) is unimplemented. It is needed to compile the `libc-test` `libtest.a`.
[src/unistd/src/lib.rs]: https://github.com/redox-os/relibc/blob/a1baf1c92df4681fba75e31489c26c...The current implementation of [getopt] (in [src/unistd/src/lib.rs]) is unimplemented. It is needed to compile the `libc-test` `libtest.a`.
[src/unistd/src/lib.rs]: https://github.com/redox-os/relibc/blob/a1baf1c92df4681fba75e31489c26cc1babfe4c1/src/unistd/src/lib.rs#L208
[getopt]: http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.htmlhttps://gitlab.redox-os.org/redox-os/relibc/-/issues/81wait: Implement the stat_val functions2018-06-14T13:45:32ZDan Robertsonwait: Implement the stat_val functionsImplement the macros used to extract useful infrom from the [Status Information] of a `wait` or `waitpid` call. The [spec] and [musl implementation] may be useful references.
- [ ] `WIFEXITED`
- [ ] `WEXITSTATUS`
- [ ] `WIFSIGNAL...Implement the macros used to extract useful infrom from the [Status Information] of a `wait` or `waitpid` call. The [spec] and [musl implementation] may be useful references.
- [ ] `WIFEXITED`
- [ ] `WEXITSTATUS`
- [ ] `WIFSIGNALED`
- [ ] `WTERMSIG`
- [ ] `WIFSTOPPED`
- [ ] `WSTOPSIG`
- [ ] `WIFCONTINUED`
[Status Information]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_13
[spec]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
[musl implementation]: https://git.musl-libc.org/cgit/musl/tree/include/sys/wait.h#n47https://gitlab.redox-os.org/redox-os/relibc/-/issues/83malloc() does not properly allocate memory for sizes larger than 1706 bytes.2018-07-13T18:59:40ZJeremy Sollermalloc() does not properly allocate memory for sizes larger than 1706 bytes.*Created by: Tommoa*
I noticed this while trying to `calloc()` a buffer of 4096 bytes and it was causing a segmentation fault.
After some trial and error, it turns out that whenever I tried to allocate more than 1706 bytes, the `mems...*Created by: Tommoa*
I noticed this while trying to `calloc()` a buffer of 4096 bytes and it was causing a segmentation fault.
After some trial and error, it turns out that whenever I tried to allocate more than 1706 bytes, the `memset()` portion would cause a segmentation fault at some point. I have included the code that I used to cause this error and the compilation step.
```C
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char ** argv) {
int amount = 0x6ab; // 0x6aa works
printf("%d\n", amount);
char *mem = calloc(amount, 1);
free(mem);
return 0;
}
```
`gcc -fno-stack-protector -Wall -nostdinc -nostdlib -I include -I target/include target/debug/libcrt0.a "test.c" target/debug/libc.a; ./a.out`https://gitlab.redox-os.org/redox-os/relibc/-/issues/71wait: Implement waitpid2018-07-13T18:59:40ZDan Robertsonwait: Implement waitpid`waitpid` has not been implemented. Redox has the `waitpid` syscall and linux has `WAIT4`. A low level platform specific wrapper for `waitpid` should be added to the `platform` crate, followed by a platform generic implementation written...`waitpid` has not been implemented. Redox has the `waitpid` syscall and linux has `WAIT4`. A low level platform specific wrapper for `waitpid` should be added to the `platform` crate, followed by a platform generic implementation written for the `wait` crate.https://gitlab.redox-os.org/redox-os/relibc/-/issues/67tests don't call relibc implementation of string functions.2018-07-13T18:59:40ZJeremy Sollertests don't call relibc implementation of string functions.*Created by: jrraymond*
I was implementing `strpbrk`, which calls `strcspn`. When called from inside my implementation of `strpbrk`, `strcspn` was crashing at `src/string/src/lib.rs:140: attempt to shift left with overflow` on the input...*Created by: jrraymond*
I was implementing `strpbrk`, which calls `strcspn`. When called from inside my implementation of `strpbrk`, `strcspn` was crashing at `src/string/src/lib.rs:140: attempt to shift left with overflow` on the inputs `hello, worlde`, `aeiouy`. However, when I called `strcspn` from the tests with the same inputs it worked.
So I commented out almost the entire implementaiton of `strcspn` so it would always return `0`. But when I run the tests `strcspn` still produces the correct results.
I also commented out most of the implementation of `strspn` and `strchr`, and they still produce the correct results. So I added back the `uniplemented!` macro and the tests still work.
I wonder if this is just some quirk of my system?