Есть ли веская причина, что исполняемый файл нуждается в предпочтительном загрузочном адресе и поэтому сохраняется код, зависящий от положения, вместо простого использования RVA по всему файлу?
Для меня это выглядит как главный недостаток дизайна, я не понимаю, как можно даже придумать эту идею.Зачем нужна позиция формата PE?
ответ
Я думаю, что причина более историческая, чем практическая.
Приводя Мэтт Pietrek из его хорошо известный "Peering Inside the PE":
Это общеизвестно, что Windows NT имеет VAX® VMS® и UNIX® наследия. Многие из создателей Windows NT разрабатывались и кодировались для платформ , прежде чем приходить в Microsoft. Когда пришло время разработать Windows NT, было вполне естественно, что они пытались свести к минимуму их время загрузки bootstrap , используя ранее написанные и проверенные инструменты. Формат исполняемого и объектного модуля , с которым были обработаны эти инструменты, и , называется COFF (акроним для формата файлов общих объектов). [...] Формат COFF сам по себе был хорошей отправной точкой, но для этого требовалось , чтобы удовлетворить все потребности современной операционной системы, например Windows NT или Windows 95. Результатом этого обновления является портативный Исполняемый формат.
Так формат PE основан на формате COFF, а потом имеет понятие relocations: они позволяют системе (точнее загрузчик системы) перебазироваться РЕ во время выполнения, исправляя положение зависимых адресов.
official PE documentation Явным образом имена Перераспределения как «COFF Relocations», поэтому я думаю, что ретрансляции PE наследуются от COFF и не являются новым дополнением, созданным самим форматом PE.
В целом, я предполагаю, что позиция независимого PE была отброшена (если даже когда-либо считаться), поскольку формат COFF уже имеет концепцию переездов, которые достигают той же функции.
- 1. Самотестирование PE-формата
- 2. О разделе кода PE-формата
- 3. Зачем нужна позиция: исправлена ошибка IE (8 или 10)?
- 4. позиция CSS нужна помощь
- 5. Позиция относительного фиксированного выравнивания. Зачем?
- 6. Нужна помощь формата даты
- 7. Зачем нужна первая звездочка?
- 8. Зачем нужна черепаха SVN?
- 9. Зачем нужна перезагрузка браузера?
- 10. Зачем нужна виртуальная функция?
- 11. Зачем нужна сущностьManagerFactory?
- 12. Зачем нужна active_support sinatra
- 13. Зачем нужна группа, где
- 14. Зачем нужна петля addrinfo?
- 15. Зачем нужна эта форма?
- 16. Зачем нужна виртуальная таблица?
- 17. Зачем нужна сумма GHC.Num.fromInteger?
- 18. Зачем нужна регистрация возврата?
- 19. Зачем нужна проверка пробела?
- 20. Зачем нужна ошибка NZEC?
- 21. Зачем нужна основная затмение
- 22. Зачем нужна «rec»
- 23. Зачем нужна внутренняя процедура?
- 24. Зачем нужна монада Maybe?
- 25. Зачем нужна угловая сфера?
- 26. Зачем нужна форма?
- 27. Зачем нужна инструкция return
- 28. Зачем нужна графика?
- 29. Зачем нужна session_ destroy()?
- 30. Зачем нужна кодировка XML?
PIC - значительная нагрузка на 32-битный код, который обеспечивает доступ к статическим данным (например, константам или поисковым таблицам), где RIP-относительная адресация недоступна. Гораздо дешевле иметь адреса, жестко закодированные в машинных инструкциях. Таким образом, либо код должен прыгать через обручи, чтобы быть независимым от положения, либо он должен иметь все эти адреса, переписанные каждый раз, когда он загружается. Второй способ потребовал бы загрузки/перемещения всего исполняемого файла во время загрузки, и он был бы частной копией для этого процесса (а не общим доступом только для чтения исполняемого файла на диске). –
Таким образом, существуют существенные причины для создания кода, зависящего от позиции, на 32-битной x86. –