ELF для разных операционных систем - в чем отличия?

код и не отличатется, в основном
различия на уровне линкера

А где можно почитать что-нибудь по теме подробнее? Насколько я понял, там различия только в сисколлах для подгрузки libc, например.

на ibm есть статья с хорошими ссылками.

исходники binutils

Спасибо, действительно познавательная статья, принялся за чтение ссылок :)

например, в Haiku используется свой, особый ELF, в целях совместимости с ABI BeOS.
Для сборки там используются свои ldscripts, скрипты линкера.

gcc собирает в *.o, эти файлы более-менее переносимы между разными OS, для одинаковых версий gcc/binuntils.
затем из *.o собранной программы собирается статическая библиотека *.lib через ar, или динамическая *.so через ld (статический линкер).
Затем ld из binutils, используя ldscripts и нужный формат выходного бинарника генерирует исполняемый бинарник (ELF для Linux/FreeBSD/Haiku, PE EXE для Windows, и т.п.)
Полученный бинарник является полностью независимым только при статической линковке, когда из *.lib + из рантайма языка все нужные функции собираются в один окончательный ELF/PE EXE, и т.п.
Если использовались динамические библиотеки *.so , то в бинарник прилинковывается stub, к которому её в момент запуска бинарника ядром OS подключаются через mmap нужные библиотеки. Это выполняет динамический линкер, реализованный в ядре ОС, рядом с загрузчиком (той частью ядра, которая реализует сисколл exec, подгружая бинарник, вызывая динамический линкер, создавая из бинарника процесс и запуская процесс на выполнение).

Подробнее это расписано в книжке Linkers and loaders, в Gentoo есть linkers-and-loaders в Portage.

Форматы бинарников в разных ОС разные — понятно, например COFF PE EXE vs. ELF , ELF в основном универсальный формат, но и в разных ОС разные ELF-ы, с точностью до ldscripts, которые использовались gcc тулчейном при сборке бинарника.

Подробнее про ldscripts есть в мануале про binutils и GCC, также может быть полезна книжка «GCC Internals».

в принципе ничего не мешает реализовать свой лоадер своего формата бинарников — в линуксе для этого есть binmisc_fmt, в MacOSX например, дефолтный формат бинарников Mach-O, но можно реализовать и загрузчик ELF-ов : http://www.osxbook.com/software/xbinary/

в Haiku например, используется свой формат ELF, со своими особыми ldscripts, и динамический загрузчик в ядре ОС немного другой, упрощённый — ELF Хайку не поддерживает все фичи ELF Linux, например.

Как отличается код, генерируемый gcc?

гугли на тему OS ABI, syscall interface, readelf и linuxemu в FreeBSD

То-есть, чтоб запустить, ELF от системы1 на системе2 нужно иметь копию системы1 в системе 2 и подсовывать бинарнику файлы системы1 а не родной? Или еще нужно делать ядерную прослойку?

То-есть, чтоб запустить, ELF от системы1 на системе2 нужно иметь
копию системы1 в системе 2 и подсовывать бинарнику файлы
системы1 а не родной? Или еще нужно делать ядерную прослойку?

Ядерная прослойка конечно нужна, или нечто выполняющие ее функции.

Во времена распространенности разных интел юниксов была такая штука как iBCS . С ее помощью гоняли оракл под SCO под линуксом, например.

Естественно всякие системные сервисы сами собой не появятся, типа графики. Так что для систем с ELF но не-юникс речь может идти в таком упрощенном варианте только о запуске CLI приложений.

То-есть, чтоб запустить, ELF от системы1 на системе2 нужно иметь копию системы1 в системе 2 и подсовывать бинарнику файлы системы1 а не родной?

Чтобы запустить, например, elf x86 на системе amd64 без multilib,
нужно иметь загрузчик ld-linux.so.2 в /lib и связанные с этим elf 32-битные разделяемые библиотеки (readelf -d). Ну и опцию для поддержки 32-битных исполняемых файлов в ядре.