commit 09cb17e6
Author: jD91mZM2 <me@krake.one>
Date:   Mon Aug 10 18:03:20 2020 +0200

    comment out cargo tests

commit 1915c730
Author: jD91mZM2 <me@krake.one>
Date:   Mon Aug 10 17:58:52 2020 +0200

    Update redoxer docker image

Also weaken `__floattidf`

See merge request !299

Fix CI

See merge request !302

Make linker work somewhat on Redox

See merge request !296

jD91mZM2 authored 4 years ago and Jeremy Soller committed 4 years ago

Seems to collide with the program being loaded

Fixes link error with ion shell.

Make munmap use funmap2

See merge request !297

Dlopen dlclose dlsym

See merge request !290

It is fact that ld.so has libc statially linked into it.

Normally we wouldn't need ld.so functionality once the program is
finalyl loaded, but with the next few patches, we will have dlopen which
will reuse the same ld.so functionality.

The problem is that it seams that huge part of the code is possible not
referntially transparent. That is, it is not impossible that some of the
functions have internals states. So when using the struct Linker that is
initialized by ld.so's copy of libc. we must access it using the same
copy even if both copies are identical.
For example in dlopen if you do linker.load_library(..). That would
segfault because it is using the function from libc not ld.so

So I don't truly undestand why should this be needed, but after long
hours of being stuck I thought maybe.. maybe that is the issue and
indeed it turned out to be so.

I by mistake commented _dl_debug_state() function which would break
debugging

Allocator

See merge request !295