Reasons to fork glibc
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