Fix wrong TLS resolving

See merge request !294

I attempted fixing this issue before at 43fbaf99. Although it did work,
it worked wrong, and it was just consistently working (but in wrong way)
until it didn't.

Since this is (hopefully) the real fix, I will try to explain exactly
what is going on.

This is explaination by example:

our TLS is memory of size 0x1000 starting at 0x7ffff6c50000,
but the real size is 0x000068 so we have padding stored at master.offset
= 0xf98

Now our symbol looks as follows

  Offset          Type                Sym. Value    Name
000000432b20  R_X86_64_DTPOFF64   0000000000000058 errno

The old code did 0x7ffff6c50000 + 0xf98 + 000000432b20 which is
obviosly overflowing the memory and wrong.

The right way 0x7ffff6c50000 + 0xf98 + 0000000000000058.

THe Tls base part and offset are added at __tls_get_addr function.
What is left is storing the 0x58 at the relocation address. The problem
is that we don't have 0x58, but we have (binary base + 0x58) in global
symbol table and binary base so what we store is the (binarybase + 0x58
- binary base).

I hope this does turn out to be wrong.

Add fwide function

See merge request redox-os/relibc!291

When a byte-oriented stream function touches a stream, that stream
should be set to byte-oriented mode if it hasn't been set yet. If
it has been set, the opertion should only succeed if the stream is
already in byte-oriented mode.

Signed-off-by: Wren Turkal <wt@penguintechs.org>

Signed-off-by: Wren Turkal <wt@penguintechs.org>

Signed-off-by: Wren Turkal <wt@penguintechs.org>

This function is used to set the orientation of a stream to either
byte-oriented or wchar-oriented.

More info on this function is here:
https://man7.org/linux/man-pages/man3/fwide.3p.html



This implementation only impmlemnts the manual switching and does
not yet guard against using a byte-oriented stream with wchar
functions and vice versa. Those step will come in additional
commits.

Signed-off-by: Wren Turkal <wt@penguintechs.org>

Various socket-related changes and other

See merge request redox-os/relibc!289

Oops, forgot to initiate the pointer after uses of CVec::new()

I don't really know for sure what all these silly rules are, but I think
I got it now...

GNU binutils also uses _FNMATCH_H for a guard, maybe along others!

Rename lcg48 module as rand48

See merge request !287

Don't assume u32 alignment of random() state buffer

See merge request redox-os/relibc!286

Fix bugs in handling non pie elfs

See merge request !285

The problem here was that we alway added the base address, and we
assumed that all addresses we access are relative but this is not the
case in case of non pie binaries. The issue is that all addresses were
base+offset. so if we added the base again it will ofcourse generate
wrong address.

Use C type names in byteorder functions

See merge request !274

Add test for ctime_r(), replace mem::uninitialized()

See merge request !273

Implement random() and friends

See merge request !284

Ld library path

See merge request !279

Get rid of assembly code in call_inits_finis

See merge request !282

Socket fix

See merge request !281

Rust's TcpListener fails because of the address format being wrong. The format
comes from `accept`, but there we internally use this function.

Headers

See merge request !280

This was triggered by gcc for some reason It included sys/types.h and
assumed sys/select.h to be there. And that seams to be the case in musl.

The problem with relibc here is that sys/types.h is are part of relibc
"include/*.h" files, while sys/select.h is generated by cbindgen. That
makes it impossible to #include select.h in types.h epsecially that
there are files like fcntl.c that uses types.h. They would complain
about missing headers. I fixed this by renaming sys/types.h to
sys/types_internal.h and then generating types.h using cbindgen as well
except for that. however fcntl and dlmalloc can include types_internal
instead of types.h

The problem here is that _Bool type is not defined in C++ yet this file
is using it. That leads to issues when compiling gcc. I borrowed the
same techniques used in other stdbool.h

This patch implements access function for both redox and linux and makes
sure that neither access errno variable

no name authored 4 years ago and Ahmed Abd El Mawgood committed 4 years ago

This reverts commit d9bacaec.

no name authored 4 years ago and Ahmed Abd El Mawgood committed 4 years ago

This reverts commit b0dde81c.

The main issue was not with "access" being used, it was with errno being
accessed. This patch accesses errno as well

LD_LIBRARY_PATH="/folder/with/no/libc" ./a.out

gives segfault with the following stack trace

0x00000000004d1cae in relibc::platform::sys::e (sys=18446744073709551614) at src/platform/linux/mod.rs:54
 54                  errno = -(sys as isize) as c_int;
(gdb) bt
 #0  0x00000000004d1cae in relibc::platform::sys::e (sys=18446744073709551614) at src/platform/linux/mod.rs:54
 #1  0x00000000004d361e in <relibc::platform::sys::Sys as relibc::platform::pal::Pal>::open (path=0x5555555634c0, oflag=524288, mode=0) at src/platform/linux/mod.rs:330
 #2  0x000000000049a2ad in relibc::fs::File::open (path=0x5555555634c0, oflag=524288) at src/fs.rs:28
 #3  0x0000000000482b49 in relibc::ld_so::linker::Linker::load_recursive (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:119
 #4  0x0000000000484963 in relibc::ld_so::linker::Linker::load_library (self=0x7fffffffdd30, name=...) at src/ld_so/linker.rs:184
 #5  0x0000000000483b53 in relibc::ld_so::linker::Linker::load_data (self=0x7fffffffdd30, name=..., data=...) at src/ld_so/linker.rs:152
 #6  0x00000000004831fe in relibc::ld_so::linker::Linker::load_recursive (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:140
 #7  0x000000000048228a in relibc::ld_so::linker::Linker::load (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:97
 #8  0x0000000000414a3b in relibc_ld_so_start (sp=0x7fffffffe310, ld_entry=4198896) at src/ld_so/start.rs:182
 #9  0x0000000000401209 in _start () at src/ld_so/src/lib.rs:10
 #10 0x0000000000000001 in ?? ()
 #11 0x00007fffffffe592 in ?? ()
 #12 0x0000000000000000 in ?? ()