Comments 17
А какие современные компиляторы в нативный код используют OMF ?
Понятно, что не всякий линкер для этого подойдет. Помнится, солярисовский Sun PRO компилятор именно поэтому использовал свой, интеллектуальный линкер ldi (или ild? Склероз проклятый). Можно было и gcc-шный ld подсунуть, и он даже работал — но ровно до тех пор, пока дело не доходило до линковки с «внешним» шаблонным кодом.
А в TinyC пошли наоборот, сделали ELF и для Windows. Исторически, видимо сложилось.
А что происходит с поддержкой отладчиков и всяких исключений SEH, которые разные для 32 и 64-бит ?
Они не разные
Например вот так https://habr.com/ru/post/536990/
Так речь идет об адресации в пределах EXE-файла. Да, там есть команды типа mov rax,<переменная>, т.е. адресация в 8 байтном поле.
И в структурах самой программы полно указателей и прочего. Но в этих случаях старшие 4 байта просто остаются нулевыми, а младшие - нормально настраиваются через имеющийся OMF.
А какое преимущество дает загрузка по такому странному адресу 140000000 ? Если оставлять загрузку из IA-32, по крайней мере, можно код короче записать и, да, маленьким прицепом-бонусом можно по-прежнему использовать OMF после пустяшной доделки.
А здесь в чем плюсы? Например, при тестировании я загружал в RSP большое значение и если в недрах системных подпрограмм случайно был оставлен ESP вместо RSP, то в этом месте старшая половина RSP обнулялась и сразу все падало. Удачный тест, но зачем в обычных задачах такое значение стека? Наверное, есть задачи, где свой код требуется отодвинуть в памяти подальше, но большинство задач этого не требует. И, кстати, LLVM и OMF ортогональные вещи. Зачем же отказываться от OMF, который еще 40 лет назад прекрасно позволял собирать выполняемый модуль, не тащя в него библиотеки целиком?
А что с вызовами функций из разделяемых библиотек? Ведь нету гарантии, что они будут загружены в нижние 4Гб адресного пространства, а значит нужно будет делать вызовы через восьмибайтные указатели.
OMF еще послужит