Handle (either support correctly, or forbid) non-fPIC shared objects #1004
Description
This issue comes from this thread by @wkozaczuk: https://groups.google.com/d/msg/osv-dev/F7OAss6WNb0/SbIo2jPqBwAJ
OSv needs to relocate a shared object to an arbitrary memory offset we loaded it. According to my current understanding, both position-dependent (no -fPIC) and position-independent (-fPIC) code can be relocated. But, to relocate position-dependent code, one needs to modify the executable code (text segment) itself, while position-independent code uses a separate relocation table (PLT).
The former (position-dependent-code relocation) has a bunch of downsides - most importantly it means a multi-process OS like Linux can't share multiple copies of the same executable code in memory. This is why it is discouraged. But it doesn't mean it can't work!
We may be able support non-fPIC shared objects by noticing the DT_TEXTREL marker exists, and then map all the segments with forced write permissions, do all the relocations up-front, and then in fix_permissions(), mprotect() all the segments with the desired final permissions - not just the relro segment.
Alternatively, we can decide not to bother with this, and insist that -fPIC be always used (as it is anyway recommended) when building code for OSv. In that case, we should check for the existence of DT_TEXTREL and refuse to load such object, stating that -fPIC should have been used (we already have other cases where we throw invalid_elf_error exceptions when we don't like the executable).