redox issueshttps://gitlab.redox-os.org/redox-os/redox/-/issues2024-01-13T07:07:30Zhttps://gitlab.redox-os.org/redox-os/redox/-/issues/1417Implement the "make prefix compiler" command2024-01-13T07:07:30ZRibbonImplement the "make prefix compiler" commandThe [proposal](https://gitlab.redox-os.org/redox-os/redox/-/issues/1389) to move the rustc source fetch to the `make prefix` command is redundant because it's called with `make all`, you would clone the rustc sources later.
My solution ...The [proposal](https://gitlab.redox-os.org/redox-os/redox/-/issues/1389) to move the rustc source fetch to the `make prefix` command is redundant because it's called with `make all`, you would clone the rustc sources later.
My solution is to add a specific command to fetch and build from sources (the CI server need this), see the current behavior:
- `bootstrap.sh` - rustc is a submodule, thus it clone the sources on each build system copy.
- `make prefix` - It download the toolchain binaries from the CI server and build relibc.
My proposed behavior:
- `make prefix compiler` - Active the `PREFIX_BINARY=0`, download the rustc/GCC sources and build the toolchain (`bootstrap.sh` don't fetch the rustc sources anymore).https://gitlab.redox-os.org/redox-os/redox/-/issues/1241Lint and test the codebase with gitlab CI2023-06-13T04:10:27ZThomas LaferriereLint and test the codebase with gitlab CIAdding a `gitlab-ci` job for linting the code at every commit and running automated tests using `gitlab-ci` would be a great improvement for developer productivity and would ensure constant quality assurance. At the moment the `.gitlab-c...Adding a `gitlab-ci` job for linting the code at every commit and running automated tests using `gitlab-ci` would be a great improvement for developer productivity and would ensure constant quality assurance. At the moment the `.gitlab-ci.yml` file is only used to generate the `.iso` images. Setting up runners would probably be necessary for cross-platform testing. It could use clippy for this purpose relating this to #351 or simply run `rustfmt` as suggested in the [docs' style page](https://doc.redox-os.org/book/contributing/best_practices/style.html). I've created this issue in response to that page.https://gitlab.redox-os.org/redox-os/redox/-/issues/927dynamic linking support2023-06-13T04:42:46ZJeremy Sollerdynamic linking support*Created by: m4b*
Currently redox requires statically linked ELF binaries.
So first question, are there any plans to support dynamic linking?
If so, would you consider using/adopting [dryad](https://github.com/m4b/dryad) ? In short, ...*Created by: m4b*
Currently redox requires statically linked ELF binaries.
So first question, are there any plans to support dynamic linking?
If so, would you consider using/adopting [dryad](https://github.com/m4b/dryad) ? In short, I would love to see a home/use for it, considering all the work that went into it, and would be willing to help port it over to Redox/mentor anyone who wants to help on that front, once a direction is decided.
The long is I'll give some motivations for adopting it as the dynamic linker if there are such plans, and some difficulties/considerations to be made about creating a dynamic linking platform.
Dryad started as an experiment to write a parallel dynamic linker (I still thinks this is possible) and also just because I was interested in their design. I originally targeted only x86-64, but since have added support for 32-bit arm (which I've successfully tested on my arm phone), as well as 64-bit arm (unfortunately I cannot currently link it properly (missing symbols), but I suspect it will work with some tweaking). And by successful, I mean it segfaults ;)
Along the way, I encountered serious technical issues deep in GNU's libc/ld-linux-so-x86_64 which made development difficult (and uninteresting) - as I would essentially be required to copy the unspecified ABI of glibc's internal structs, in particular, `rtld_global_ro` - let alone any other libc. The common theme here appears that most libc's cache results from locales, `auxv` accesses, and sometimes environment variable pointers in a secret, non-standardized struct that the dynamic linker has access to. But this pervasiveness goes even further - in recent versions of my glibc, (2.25), the `GNU_IFUNC` resolver for `__exp_finite` accesses the dynamic linker struct (which has not been initialized because the dynamic linker isn't the glibc dynamic linker), and hence segfaults. There's really no way to know that any arbitrary function in glibc (which can access the `rtld_*` structs because it's built in the same compilation unit as the dynamic linker) is going to rely on this private, practically uninitializable struct.
Consequently, I largely stopped working on `dryad`, except for keeping it up to date and still compiling. If you do anything, _do not make this mistake_ that glibc made. At the very least, specify the structure and expected runtime values required to initialize and load any libraries, similar to the PLT/GOT specification. They fused their libc implementation with their dynamic linking implementation, for seemingly for no particularly good reason. (musl libc's intentionally does this - musl libc binary _is_ the dynamic linker too). Here is a more in depth, fairly sarcastic and tongue-in-cheek investigation of this issue: https://github.com/m4b/dryad/issues/5
Nevertheless, in terms of features, I think it is quite robust:
0. Correctly relocates and can run itself (e.g., `./dryad.so.1`)
1. multiple architectures (someone needs to write `AARCH64` assembly stubs for runtime resolution, as well asm stubs for `i386`)
2. gdb support (this was particularly vexing as there was no documentation on how to do this)
3. runtime (aka lazy) symbol resolution
4. partial (read currently non-working) TLS initializer/implementation - largely adopted from glibc/musl. I just use the internal musl implementation for now
5. Partial support for dynamic linking environment variables, e.g., `LD_DEBUG`, `LD_BIND_NOW`, etc.
6. All major relocation directives are supported, including `GNU_IFUNC` (more exotic x86 relocations are ignored, but most of these aren't emitted by any major toolchain anymore)
7. Fairly painless rustup + makefile compilation (this is substantially more work than you would think, see the `Makefile` if you don't believe me)
8. Uses gnu hashes/bloom filter for symbol resolution which makes it extremely fast (probably need to also support regular hashes, but I wasn't that interested since every linux linker emits GNU_HASH dynamic entries)
If this sounds good I would be interested in helping get dryad ported to work on a redox system; this will be some work, as there are a few linux assumptions made, but I don't think that in particular will be the difficult part.
The first issue will be hammering down the TLS implementation, as this is potentially the most OS-based assumption (besides `auxv` accesses, or how the so-called "kernel block" is setup). Ideally, I would like the implementation in `tls.rs` to have essentially a single entry-point across multiple systems, where the implementation is switched at compile time depending on the OS target. This particular area was/still is a WIP, and currently I just default to using the statically linked musl initializer.
I haven't looked at redox, so I don't know what requirements are here, how it sets up the the TLV, TP, etc. But since it seems able to run x86 ELF binaries (which I assume must be accessing the re-appropriated `fs` or `gs` segmented registers for TLS), it is perhaps the same?
The second issue is essentially what kind of runtime system library you want (e.g., a libc), and in the case of reusing glibc, what to do about the `rtld_*` problem. If you do end up just using glibc, then you are likely committed to using their dynamic linker (unless someone feels like cloning the ABI of libc and having dryad pretend it is `ld-linux`)
This last issue is the hard part I believe, and it's really more of an infrastructure issue/planning/what kind of system do you want to build problem, and all the pros and cons associated with any decision thereof.
Anyway, I've typed enough; let me know what you think. My feelings won't be hurt if you do want to implement dynamic linking, but don't want to use dryad as your dynamic linker. I'm just looking for a home for all the code that was written at this point, but if not, that's ok too :)https://gitlab.redox-os.org/redox-os/redox/-/issues/765Identify supported hardware2023-06-13T04:42:45ZJeremy SollerIdentify supported hardwarePublicly list all of the hardware Redox supports.
To start: Redox supports x86-64, and I have tested on a number of CPUs with success. All VESA-compatible cards are supported (which is most graphics cards). AHCI (SATA) is supported, but...Publicly list all of the hardware Redox supports.
To start: Redox supports x86-64, and I have tested on a number of CPUs with success. All VESA-compatible cards are supported (which is most graphics cards). AHCI (SATA) is supported, but not IDE (PATA) or NVMe at the moment. USB is not supported yet. As for network cards, the E1000 series Intel cards are supported, as well as the RTL8169. More cards will be supported soon.Boot Failureshttps://gitlab.redox-os.org/redox-os/redox/-/issues/647OS level support for TLS sockets2023-06-13T04:42:45ZJeremy SollerOS level support for TLS sockets*Created by: NilSet*
TLS (aka SSL) in the form of libraries like OpenSSL is unwieldly to use. We should expose a sockets api which is in line with other socket types like raw, TCP, and UDP sockets, using sane default parameters which ca...*Created by: NilSet*
TLS (aka SSL) in the form of libraries like OpenSSL is unwieldly to use. We should expose a sockets api which is in line with other socket types like raw, TCP, and UDP sockets, using sane default parameters which can be tweaked through setsockopt.