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

Seems to collide with the program being loaded

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

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.

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>

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!

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.