Независимо от платформы объектных файлов?

Ответ 1

Нет. В общем случае форматы объектных файлов могут быть одинаковыми, например. 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 ?

Совершенно верно. Если вы используете кросс-компилятор. Этот компилятор специально ориентирован на платформу и генерирует объектные файлы (и программы), которые совместимы с целевой платформой. Таким образом, вы можете использовать систему X86 Linux, например, для создания программ для системы powerpc или ARM с использованием соответствующего кросс-компилятора. Я делаю это здесь.

Ответ 2

Можно ли скомпилировать программу на одной платформе и связать ее с другими?

В общем, нет. Объектные файлы специфичны для компилятора. Некоторые компиляторы выплевывают COFF, другие выскакивают ELF и т.д. Кроме того, вам приходится беспокоиться о вызовах, системных вызовах и т.д. Это зависит от платформы.

Что содержит объектный файл?

Символьные таблицы, код, перемещение, связывание и отладка информации.

Если вам нужна переносимость, напишите переносимый C/С++ и пусть компилятор, совместимый с платформой, выполнит эту работу.

Ответ 3

На практике нет. Есть несколько вещей, которые должны быть одинаковыми: - Интерфейс ОС (те же системные вызовы) - макет памяти данных (endianness, прокладка структуры и т.д.) - вызов конвенции - формат объектного файла (например, ELF является довольно стандартным для Linux)

Поиск ABI для получения дополнительной информации.

Ответ 4

Это не нужно повторять: объектные файлы C/С++ не переносятся.

С другой стороны, ANSI C является одним из самых портативных языков. Возможно, вы не сможете получить объектные файлы, но перекомпиляция вашего источника, скорее всего, будет работать, если вы придерживаетесь стандарта ANSI C. Это также может быть верно и для С++.

Я не знаю, насколько универсален GNU С++, но если вы можете скомпилировать gcc на одном компьютере, вы можете пойти на любую другую машину, на которой также установлена ​​gcc. Почти каждая машина, о которой вы можете думать, имеет компилятор C. Это переносимость.

Ответ 5

Нет. Они не являются независимыми от платформы. Возьмем, к примеру, компилятор GNU C (gcc), который генерирует двоичные файлы ELF. Компиляторы Windows (Borland, Microsoft, Open Watcom) могут создавать формат Windows Binary PE (Portable Executable). Бинарники Novell - это модуль NLM (Netware Loadabable Module).

В приведенных выше примерах различных выводов, зависящих от компилятора, нет никакого способа, компоновщик на платформе Windows, знать что-либо о формате ELF или формате NLM, поэтому невозможно объединить разные форматы для создания исполняемого файла, который может работать на любой платформе.

Возьмите Apple Mac OSX (до того, как были установлены чипы Intel), они работали на платформе PowerPC, даже если у нее есть компилятор GNU C, двоичный файл специально предназначен для платформы PowerPC, если вы должны принять это бинарно и скопировать его на платформу Linux, он не будет работать в результате различий в инструкциях микропроцессора платформы, то есть PowerPC.

Опять же, тот же принцип применим к системе мейнфреймов OS/390, компилятор GNU C, который создает двоичный файл для этой платформы, не будет работать на предустановленной Apple Mac OSX.

Изменить: Чтобы уточнить, как выглядит формат ELF, см. ниже, это было получено при запуске 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 и является форматом ELF для процессора i386.

Надеюсь, это поможет, С наилучшими пожеланиями, Том.

Ответ 6

Они зависят от платформы. Например, команда file-command выводит следующие данные:

$ file foo.o
foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Ответ 7

В С++ есть дополнительная информация о том, что имена, которые он помещает в объектный файл, как правило, "искалечены" для обеспечения безопасности типов для перегруженных имен. Методы, используемые для манипулирования именами, не являются частью стандарта С++ (на самом деле, определение имени - это деталь реализации, которая не требуется вообще, если поставщик может придумать другой способ реализации перегрузки). Таким образом, даже для одной и той же целевой платформы вы не можете рассчитывать на возможность связывания объектных файлов с одним поставщиком компилятора на другой.

Бывают случаи, когда поставщик компилятора может изменить схему переключения имен из одной версии компилятора в другую. Например, я считаю, что существуют версии MSVC, для которых вы не можете надежно связывать объектные файлы С++ от более старой версии до более новой версии.

Некоторые платформы имеют имя, указанное в стандарте ABI для платформы (например, ARM, которая использует имя, указанное в общем С++ ABI, которое было первоначально разработано для SVr4 на Itanium), но другие не делают (Windows), Даже для ARM я не уверен, насколько совместим стандарт ABI, который связывает файлы объектов С++, созданные разными компиляторами.

Ответ 8

Я просто хотел сказать, что до тех пор, пока они используют одну и ту же архитектуру процессора и формат объекта, а также соглашение о вызове (обычно в настоящее время создатель процессора создает его), существует много шансов, что объектные файлы будут работать взаимозаменяемо.

Однако даже в C компилятор делает некоторые предположения относительно некоторых функций библиотеки, таких как защита стека (что я знаю), которые не обязательно должны быть одинаковыми на обеих платформах. в случае создания такого кода объекты не будут напрямую совместимы.

Системные вызовы не имеют особого значения, если системы совместно используют их вообще, как обычно, они вызываются через C-оболочки в стандартных библиотеках.

В конце это относится только к C и очень похожим операционным системам, таким как Linux и BSD, но это может произойти.

Ответ 9

Возможно компиляция с GCC и создание объектного файла в формате файла ELF и преобразование объектного файла в Visual Studio. Я сделал это несколько раз.

Для этого вам нужно знать три вещи: соглашение о вызове функции, формат объектного файла и название функции.

Соглашения о вызовах функций: В 32-битном режиме процедура вызова вызова проста: они одинаковы для Windows и Unix. Для 64-битного режима Windows и Unix используют разные соглашения о вызовах. Таким образом, в 64-битном режиме вы должны правильно принять соглашение о вызове. Это можно сделать при компиляции или из самого файла объекта. Это намного проще сделать, когда вы компилируете. Чтобы GCC использовал соглашение о вызове Windows, используйте -mabi=ms. Для этого из объектного файла нужен инструмент. Agner Fog objconv инструмент может сделать это для некоторых функций.

Формат файла возражения:. Для преобразования формата объектного файла необходим инструмент. Для этого я использую инструмент Agner Fog objconv. Он может конвертировать из нескольких форматов объектных файлов. Например, для преобразования ELF64 в COFF64 (PE32 +) выполните objconv -fcoff64 foo.o foo.obj.

Назначение имени функции: Из-за перегрузки функций в компиляторах С++ кадровые имена функций. Подробности для каждого компилятора можно найти в руководстве Agner Fog вызове convetions. GCC и Visual Studio изменяют имена функций по-разному. Чтобы обойти это исправление текущей функции с помощью extern "C"

Если вы получаете все три из них правильно, и вы не делаете никаких конкретных вызовов ОС, вы сможете успешно использовать свои объектные файлы между компиляторами. Конечно, есть и другие проблемы. См. Руководство в objconv для получения более подробной информации. Но до сих пор этот метод работал хорошо для меня.