Платформа файлов действительно ли объекта независима?
Действительно ли возможно собрать программу на одной платформе и ссылку с другим? Что содержит файл объекта? Мы можем отделить исполняемый файл, чтобы создать файл объекта?
8 ответов
Нет. В общем объекте форматы файлов могут быть одинаковыми, например ELF, но содержимое объектных файлов будет варьироваться от системы в системе.
Объектный файл содержит такие вещи, как:
Object code that implements the desired functionality
A symbol table that can be used to resolve references
Relocation information to allow the linker to locate the object code in memory
Debugging information
Объектный код обычно не только конкретный процессор, но и конкретный, если он, например, он содержит системные вызовы.
Править:
Is it possible to compile program on one platform and link with other ?
абсолютно. Если вы используете кросс-компилятор. Этот компилятор специально ориентирован на платформу и генерирует объектные файлы (и программы), которые совместимы с целевой платформой. Таким образом, вы можете использовать систему Linux X86, например, для создания программ для системы на основе PowerPC или ARM, используя соответствующий кросс-компилятор. Я делаю это здесь .
На практике нет. Есть несколько вещей, которые должны были бы быть одинаковыми: - Интерфейс ОС (такие же системные звонки) - Память памяти данных (целевость, структура и т. Д.) - Конвенция о вызове - Формат файла объекта (E.G. ELF довольно стандартный на Linux)
поиска ABI для получения дополнительной информации.
Это зависит от платформы. Например, файловая команда отпечатывает следующее:
$ file foo.o
foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Нет. Они не независимы от платформы. Примите, например, компилятор GNU C (GCC), который генерирует двоичные файлы ELF. Компиляторы Windows (Borland, Microsoft, Open Watcom) могут создавать формат Windows Binary PE (портативный исполняемый файл). Novell Binaries являются форматом NLM (модуль NetWare Loadabable).
Эти примеры выше различных выходов, которые зависят от компилятора, в зависимости от компилятора нет способа, линкер на платформе Windows, знал бы что-нибудь о формате ELF, ни формата NLM, следовательно, нельзя комбинировать различные форматы для создания исполняемого может работать на любой платформе.
Возьмите MAC OSX Apple (до того, как чипы Intel вставлены), они работали на платформе PowerPC, даже если у нее есть компилятор GNU C, двоичный элемент специально для платформы PowerPC, если вы должны были взять это Бинарный и скопируйте его на платформу Linux, она не будет работать в результате различий в инструкциях микропроцессора платформы, т.е. PowerPC.
Опять же, тот же принцип будет применяться к системе MainFrame OS / 390, компилятор GNU C, который производит двоичный для этой платформы, не будет работать на предварительно Intel Apple Mac OSX.
Редактировать: Для дальнейшего уточнения того, как будет выглядеть формат эльфа, как можно увидеть ниже, это было получено запущенным objdump -s main.O под Linux.
main.o: file format elf32-i386 Contents of section .text: 0000 8d4c2404 83e4f0ff 71fc5589 e55183ec .L$.....q.U..Q.. 0010 14894df4 a1000000 00a30000 0000a100 ..M............. 0020 000000a3 00000000 8b45f483 38010f8e .........E..8... 0030 9c000000 8b55f48b 420483c0 048b0083 .....U..B....... 0040 ec086800 00000050 e8fcffff ff83c410 ..h....P........ 0050 a3000000 00a10000 000085c0 7520a100 ............u .. 0060 00000050 6a1f6a01 68040000 00e8fcff ...Pj.j.h....... 0070 ffff83c4 10c745f8 01000000 eb5a8b45 ......E......Z.E 0080 f4833802 7e218b55 f48b4204 83c0088b ..8.~!.U..B..... 0090 0083ec08 68240000 0050e8fc ffffff83 ....h$...P...... 00a0 c410a300 000000a1 00000000 85c07520 ..............u 00b0 a1000000 00506a20 6a016828 000000e8 .....Pj j.h(.... 00c0 fcffffff 83c410c7 45f80100 0000eb08 ........E....... 00d0 e8fcffff ff8945f8 8b45f88b 4dfcc98d ......E..E..M... 00e0 61fcc3 a.. Contents of section .rodata: 0000 72000000 4552524f 52202d20 63616e6e r...ERROR - cann 0010 6f74206f 70656e20 696e7075 74206669 ot open input fi 0020 6c650a00 77000000 4552524f 52202d20 le..w...ERROR - 0030 63616e6e 6f74206f 70656e20 6f757470 cannot open outp 0040 75742066 696c650a 00 ut file.. Contents of section .comment: 0000 00474343 3a202847 4e552920 342e322e .GCC: (GNU) 4.2. 0010 3400 4.
Теперь сравните, что формат PE для простой DLL
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin>dumpbin /summary "C:\Documents and Settings\Tom\My Documents\Visual Studio 2008\Projects\SimpleLib\Release\SimpleLib.dll"
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\Documents and Settings\Tom\My Documents\Visual Studio 2008\Projects\SimpleLib\Release\SimpleLib.dll
File Type: DLL
Summary
1000 .data
1000 .rdata
1000 .reloc
1000 .rsrc
1000 .text
Обратите внимание на различия в секциях под ELF, есть .bss , .text , .Rodata и .Comment и является форматом эльфа для процессора I386.
Надеюсь, это поможет, С уважением, Том.
Я просто хотел сказать, что, пока они используют одинаковую архитектуру процессора и формат объекта, а также вызова Конвенции (обычно в наши дни, процессор Maker создает один), существует много шансов на объект Файлы для работы взаимозаменяемо.
Однако даже в C компилятор приводит к тому, что некоторые предположения о определенных функциях библиотеки, такие как защита стека (что я знаю), представляющуюся, что не должно быть одинаковым на обеих платформах. В случае, если такой код генерируется, объекты не будут напрямую совместимы.
Системные вызовы на самом деле не актуальны до тех пор, пока системы делятся ними, как правило, они называются с помощью Cnapers в стандартных библиотеках.
В конце концов это относится только к C и очень похожие ONES, такие как Linux и BSD, но это может произойти.
C ++ имеет дополнительную деталь, что имена, которые он помещают в объектный файл, обычно «Mangled» для защиты типов для имен, которые перегружены. Методы, используемые для скончающих имен, не являются частью стандарта C ++ (на самом деле, имя Mangling - это деталь реализации, которая вообще не требуется, если поставщик может придумать другой способ реализации перегрузки). Таким образом, даже для той же цели платформы вы не можете рассчитывать на возможность ссылки на объектные файлы из одного поставщика компилятора к другому.
Есть времена, когда поставщик компилятора может изменить схему Mangling имя из одной версии компилятора в другую. Например, я считаю, что есть версии MSVC, для которых вы не можете надежно ссылаться на объектные файлы C ++ из более старой версии на более новую версию.
Некоторые платформы имеют название, указанное в стандарте ABI для платформы (например, руки, которая использует имя поклонника, указанное в общем C ++ ABI, который был изначально разработан для SVR4 на Itanium), но другие не (Windows) Отказ Даже для рук, я не уверен, насколько совместно используемый стандарт ABI делает связывание объектных файлов C ++, которые были созданы различными компиляторами.
Опять не нужно говорить: файлы объектов C / C ++ не являются портативными.
С другой стороны, ANSI C является одним из самых портативных языков. Возможно, вы не сможете забрать свои объектные файлы, но перекомпиляция вашего источника, вероятно, будет работать, если вы придерживаетесь стандарты ANSI C. Это также может быть верно для C ++.
Я не знаю, насколько Universal GNU C ++ есть, но если вы можете компилировать с GCC на одном компьютере, вы хорошо отправляетесь на любой другой компьютер, который также установлен GCC. Околовая машина, которую вы можете подумать о компилятере C. Это портативность.
Можно ли компилировать программу на одной платформе и ссылку с другими?
в целом нет. Объектные файлы являются компилятором. Некоторые компиляторы вылетают COFF , другие выделяют ELF , и т. Д. Кроме того, вы должны беспокоиться о том, что требуют конвенции, системные вызовы и т. Д. Это зависит от платформы.
Что содержит объектный файл?
Символ таблицы, код, перемещение, связывание и отладка информации.
Если то, что вы после того, как переносимость, то напишите портативный C / C ++ и позвольте компилятору, специфичному платформу.