Reasons to fork glibc

[Sonicadvance1]

We really don't want to do this, but there are some reasons to go about doing this and we need to track the pain points. This list will grow as we care about more things

• clone support

  • There are a lot of clone flags that can't be accurately wrapped while using glibc
  • One of the big issues is that a guest application can be using clone directly, with flags that if we allow it breaks FEX's TLS usage.
  • This is because glibc doesn't provide us a way to do clone flags plus keeping our TLS setup working
  • We would need to fork glibc to expose a subset of flags AND keep our TLS working.

• 32-bit thunks

  • In order to keep 32-bit VA usage down, we will need to wrap the mmap and munmap usage inside of glibc's dynamic loader
  • The 32-bit side of the thunk stays in the 32-bit VA space.
  • A significant amount of the 64-bit side could live in 64-bit VA space
  • Exported symbols would need to still live in the 32-bit VA, which means the full host library also needs to live in the 32-bit VA, or we need to duplicate the symbol inside of the 32-bit space

• Guest thunk hooks

  • Add support for hooking when symbols are loaded so we can partially thunk a library
  • A bit gross but would work for partial thunking?

• Guest thunk callback support

  • If the thunk creates a thread and is expected to call in to the guest as a callback. Then TLS state doesn't exist
  • We could have a TLS region allocated for a guest thread post-thread creation if this was the case
  • Bit of a faff

[Sonicadvance1]

Another reason. Glibc has deprecated a static application calling dlopen. It technically still works today but may be removed at any moment. We've already encountered a bug where FEX loading a thunk hasn't set up glibc's allocator function pointers, causing a crash. Dangerous as a fork since we would need to forgo the host glibc entirely for even host glibc. Spooky.

[Sonicadvance1]

Another reason: With IR/Code caching we need to understand RIP relocations to named regions. Some relocations go in to the BSS region of an ELF. BSS regions aren't tracked through the named region tracking since they aren't bound to an FD. With a fork we could have an interface for defining a full named region including BSS to capture these sections.

[ifquant]

we could supply ld.so compatible with glibc, but without change libc.so. and FEXLoader is work as a libfex.so preload by ld.so. ? it seem's more reasonable.

[neobrain]

Being able to hook into longjmp could enable us to address a potential limitation of deferred asynchronous signal handling. Hooking into longjmp allows for detecting exits out of guest-provided signal handlers (see #2493 and https://github.com/FEX-Emu/FEX/blob/master/docs/DeferredSignals.md#disadvantages-of-cooperative-signal-deferring).