[gentoo-soc] Weekly Progress: Porting relibc to gentoo

[gentoo-soc] Weekly Progress: Porting relibc to gentoo

[Ahmed Soliman]

So for this week I worked on two patch sets (still trying to get gcc
to link against relibc).

While compiling Gcc using relibc, there was a stage where xgcc is
generated and linked against relibc and used to compile the rest of
the compiler. But the issue was that I was using the debug version of
relibc which is significantly slower than the release version. When I
tried switching to the release version, ld.so crashed in a very early
stage. The issue was that Relibc had some assembly code (that broke
ABI compatibility) when compiled in the release build. This patch[1]
fixes this issue by trying to replace the assembly code by pure rust.

Catching this bug was extremely complex because back then I didn't
have debug symbols to help me figure where is the bug I only had to
use prints for debugging and reading through the generated assembly

I have also worked on porting elf.h to relibc as it was needed by gcc
but not implemented yet in relibc, also gcc needed the posix defined
file locking mechanism which wasn't implemented either in relibc. Both
are implemented in this patch[2].

Thanks,
Ahmed.

[1] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/282
[2] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/283

[gentoo-soc] Weekly Progress: Porting Relibc to gentoo

[Ahmed Soliman]

So this week has been full of new stuff, I have finally have a clean
implementation for a memory allocation model based on mspaces that
fixes the old issue where we had two identical copies of malloc
accessing the same brk(), without sharing metadata at [1].

I also finalized my dlopen dlsym and dlclose implementation you can
find it at [2]

And I fixed an old bug regarding TLS resolving (I attempted fixing it
before but it seems that my old fix was not working) at [3].

Unfortunately, that is not enough for GCC to compile with relibc based
binutils; there are still more bugs, but with every step we are
getting closer..

Thanks
Ahmed.

[1] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/295
[2] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/290
[3] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/294

Re: [gentoo-soc] Weekly Progress: Porting Relibc to gentoo

[Luca Barbato]

On 19/07/2020 22:42, Ahmed Soliman wrote:
> So this week has been full of new stuff, I have finally have a clean
> implementation for a memory allocation model based on mspaces that
> fixes the old issue where we had two identical copies of malloc
> accessing the same brk(), without sharing metadata at [1].
> 
> I also finalized my dlopen dlsym and dlclose implementation you can
> find it at [2]
> 
> And I fixed an old bug regarding TLS resolving (I attempted fixing it
> before but it seems that my old fix was not working) at [3].
> 
> Unfortunately, that is not enough for GCC to compile with relibc based
> binutils; there are still more bugs, but with every step we are
> getting closer..
> 
> Thanks
> Ahmed.
> 
> [1] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/295
> [2] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/290
> [3] https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/294
> 

Please make sure to track what features were missing from the beginning
till now :)

It will be quite important in the future.

lu

Re: [gentoo-soc] Weekly Progress: Porting Relibc to gentoo

[Ahmed Soliman]

Hi,

> Please make sure to track what features were missing from the beginning
> till now :)

I already am, The proposal I submitted to GSOC is constantly being
updated with resolved issues.
I am planning to submit a copy of it when gsoc is over so that you all
can have a look at what has
been done over the span of the whole program

Thanks.
Ahmed