Почему fPIC абсолютно необходим на 64-битных, а не на 32-битных платформах?

Недавно я получил:

... перемещение R_X86_64_32 против `локального символа 'не может использоваться при создании общего объект; перекомпилируйте с ошибкой -fPIC

при попытке скомпилировать программу как разделяемую библиотеку.

Теперь решение этой проблемы не слишком сложно (перекомпилировать все зависимости с -fPIC), но после некоторого исследования это отключается но эта проблема присутствует только на платформах x86-64. На 32-битном компьютере любой код, зависящий от позиции, все еще может быть перемещен динамическим загрузчиком.

Лучший ответ , который я смог найти:

x86 поддерживает перемещение .text (что происходит, когда у вас есть позиционно-зависимый код). Такая поддержка обходится дорого, а именно: каждый страница, содержащая такое перемещение, становится закрытой, даже если она находится в разделяемой библиотеке, тем самым портя само понятие разделяемой библиотеки. библиотеки. Поэтому мы решили запретить это на amd64 (плюс он создает проблемы, если значение требует более 32 бит, потому что все .text перемещаются только имеют размер word32)

Но мне это не совсем подходит. Если перемещение портит концепцию разделяемых библиотек, почему это можно сделать на 32-битных платформах? Кроме того, если необходимо было внести изменения в формат ELF для поддержки 64-битной версии, то почему не все поля были увеличены в размере для их соответствия?

Это может быть второстепенным вопросом, но это мотивировано тем фактом, что ) рассматриваемый код является научным кодом, и было бы неплохо, если бы не снизилась производительность и б) эту информацию вообще невозможно было найти!

[Изменить: «Ответ»

@awoodlands ответ , вероятно, лучший «буквальный ответ», @servn добавил некоторую полезную информацию.

В поиске чтобы узнать больше о различных типах перемещений, я нашел , это и, наконец, x86_64 ABI reference (см. стр. 68) ]