ELF文件和bin文件有什么区别？
编译器最终生成的镜像中同时包含bin文件和扩展loader格式的ELf文件，两者有什么区别，特别是ELF文件的用途。
The final images produced by compliers contain both bin file and extended loader format ELf file ,what is the difference between the two , especially the utility of ELF file.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Bin 文件是一个纯二进制文件，没有内存修复或重定位，它很可能具有要在特定内存地址加载的显式指令。而......
ELF 文件是可执行可链接格式，由符号查找和可重定位组成表，也就是说，它可以由内核加载到任何内存地址，并自动将使用的所有符号调整为距其加载的内存地址的偏移量。通常 ELF 文件有许多部分，例如“data”、“text”、“bss”等等……正是在这些部分中，运行时可以计算在何处调整符号的内存引用在运行时动态地。
A Bin file is a pure binary file with no memory fix-ups or relocations, more than likely it has explicit instructions to be loaded at a specific memory address. Whereas....
ELF files are Executable Linkable Format which consists of a symbol look-ups and relocatable table, that is, it can be loaded at any memory address by the kernel and automatically, all symbols used, are adjusted to the offset from that memory address where it was loaded into. Usually ELF files have a number of sections, such as 'data', 'text', 'bss', to name but a few...it is within those sections where the run-time can calculate where to adjust the symbol's memory references dynamically at run-time.
bin 文件只是进入 rom 或运行程序的特定地址的位和字节。您可以获取此数据并直接按原样加载它，但您需要知道基地址是什么，因为通常不在那里。
elf 文件包含 bin 信息，但它周围有许多其他信息，可能的调试信息、符号，可以区分二进制文件中的代码和数据。允许多个二进制数据块（当您将其中之一转储到 bin 时，您会得到一个大 bin 文件，其中包含填充数据以将其填充到下一个块）。告诉您有多少二进制文件以及有多少 bss 数据需要初始化为零（gnu 工具在正确创建 bin 文件时存在问题）。
elf 文件格式是一个标准，arm 发布了该标准的增强/变体。我建议每个人都编写一个 elf 解析程序来了解其中的内容，不要费心使用库，只需使用规范中的信息和结构就非常简单。有助于克服一般创建 .bin 文件以及调试链接器脚本和其他可能导致 bin 或 elf 输出混乱的 gnu 问题。
A bin file is just the bits and bytes that go into the rom or a particular address from which you will run the program. You can take this data and load it directly as is, you need to know what the base address is though as that is normally not in there.
An elf file contains the bin information but it is surrounded by lots of other information, possible debug info, symbols, can distinguish code from data within the binary. Allows for more than one chunk of binary data (when you dump one of these to a bin you get one big bin file with fill data to pad it to the next block). Tells you how much binary you have and how much bss data is there that wants to be initialised to zeros (gnu tools have problems creating bin files correctly).
The elf file format is a standard, arm publishes its enhancements/variations on the standard. I recommend everyone writes an elf parsing program to understand what is in there, dont bother with a library, it is quite simple to just use the information and structures in the spec. Helps to overcome gnu problems in general creating .bin files as well as debugging linker scripts and other things that can help to mess up your bin or elf output.
一些资源：
http://infocenter.arm.com/help/topic /com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
ELF 格式通常是默认输出编译。
如果您使用 GNU 工具链，您可以使用 objcopy 将其转换为二进制格式，例如：
或使用 fromELF 实用程序（尽管在大多数 IDE 中，例如 ADS 中内置）：
some resources:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
ELF format is generally the default output of compiling.
if you use GNU tool chains, you can translate it to binary format by using objcopy, such as:
or using fromELF utility(built in most IDEs such as ADS though):
纯二进制是一系列可执行操作码，从其 0 偏移量开始执行，** 但不仅仅是 **。
纯二进制文件通常用于微控制器、裸机编程和初始启动，其中除了 ROM 加载程序之外没有“laoder”。
纯二进制文件包括 .bss 和 .data，它们是从闪存中读取的二进制文件，就像在微控制器中一样，必须重新定位到 RAM 中的某个位置。二进制文件可以包含向量表、“rel”或“rela”重定位的符号表（请参阅 -fPIC）、got 表等。所有这些附加数据都是从ELF→二进制转换获得的，因为该特定表的地址是从ELF获得的。
二进制生成的另一个重要点是“链接器脚本”，它们生成节偏移量，以及根据声明的节在绝对跳转中使用的不同地址。
最后注意：纯二进制代码（.text）也经常被重新定位到 RAM，因为 cpu 内部 sram 通常不会太大。为此，需要使用这样的重定位表。
Pure binary is a sequence of executable opcodes to be executed from his 0 offset, ** but not only **.
Pure binaries are generally used on microcontrollers, bare metal programming and initial boots, where there is no "laoder" except the ROM loader.
Pure binaries includes .bss and .data, that from binaries that are read from flash memory as in a microcontroller, have to be relocated somewhere in ram. A binary file can include a vector table, symbol tables for "rel" or "rela" relocation (see -fPIC), got table and so on. All this additional data are obtained from the ELF->binary conversion, since the addresses of this specific tables are obtained from the ELF.
Another important point for the binary production are "linker scripts", they produce section offsets, and different addresses used in the absolute jumps depending of the declared sections.
Final note: pure binaries code (.text) is also often relocated to ram, since cpu internal sram is generally not too big. For this, such relocation tables comes into use.
我再问一个问题，
奶酪有很多种，其中一些硬如岩石。
TL;DR - 名称“binary”和“elf”具有很大的灵活性。工具集还能够生成“SREC”、ihex 等。从“原始二进制”到完整的 elf 规范，具有连续的功能。
对于许多嵌入式系统来说，它们没有 ELF 加载器。在这些情况下，您必须以二进制文件为目标（并可能通过加载代码和/或结构来修改它）。
对于托管操作系统，通常需要 ELF 格式。 ELF 格式可以指定堆栈、bss 和数据需求和位置。它还可以添加 C++ 静态构造函数、调试、跟踪、异常以及现代操作系统和工具集所需的其他功能等设施。
二进制文件没有外部可见的格式（对于工具集）。它通常有一个固定的起始地址，通常是第一个字。通常存在一些“隐藏”格式。例如，许多嵌入式 CPU 可能在二进制文件中具有加密偏移量，用于查找摘要、文件大小等。另一个例子是一些带有 ROM 代码的 nRF 芯片组，用于加载 RF 基带和应用程序代码。
这带来了两个相关的主题。
这些任务之间的区别在于它们发生的时间；构建时或运行时。例如，许多二进制文件都有“init data”部分。这是具有“启动”值的静态变量。它们从 ROM/闪存部分复制到实时 RAM 位置。这本质上是一个小型装载机。
SREC 和 iHex 介于 ELF 和二进制文件之间。数据用地址标记，数据中可能存在“间隙”。如果代码/数据是独立的和/或您有不同的内存目标，这可能是一个好处。对于不进行“嵌入式”或“固件”编程的人来说，这些概念似乎很陌生。
ELF 文件具有丰富的重定位格式和其他符号（例如调试、框架布局等）。这些表可能在运行时需要。例如，您可以/应该从'.exidx'和'.extab'数据中获取如果您想在运行时（在二进制映像中）执行堆栈跟踪，则将 ELF 转换为二进制文件。您必须安排运行时间以使用此信息来跟踪堆栈。事实上，大多数工具集都允许您将任何/所有 ELF 信息放入二进制文件中。
某些精灵信息/部分在加载时没有意义。当处理不同的目标文件（部分/完整链接）时，会解析许多“引用”。如果您有操作系统，那么它可能会在加载时解析某些引用（通过像 ld.so 这样的加载器）或将它们用于其他目的。由于编译阶段通常会生成 ELF 对象，以便稍后处理，因此许多操作系统还会有一个了解并理解 ELF 格式的加载器。
拥有 ELF 加载程序的人可能会生成一个二进制文件来压缩或加密。然后，该二进制文件将包含在 ELF 文件中，并且一个小的“加载器”部分将执行解压缩或解密步骤。
ELF 的好处是，它是一种文档化格式。因此，通过一些工作，新的工具集可以与支持 ELF 的操作系统一起使用。您有更多的互操作性和工具选择。
对于二进制文件来说，它可以支持 ELF 所做的任何事情，但是您必须自己构建所有基础设施，而且大多数人不喜欢重新发明轮子。
I will ask another question,
Well, there are many different types of cheese, some of which are hard as a rock.
TL;DR - the name 'binary' and 'elf' have lots of flexibility. Toolsets are also capable of producing 'SREC', ihex, etc. There is a continuum of features from 'raw binary' to the full elf specification.
For many embedded systems, they do not have an ELF loader. In these cases, you must target a binary (and possibly amend it with loading code and/or structures).
For a hosted OS, it is common to want an ELF format. The ELF format can specify stack, bss and data needs and locations. It can also add facilities like C++ static constructors, debugging, tracing, exceptions and other features expected from modern OS's and toolsets.
A binary has no externally visible format (to the toolset). It often has a fixed start address which is often the first word. Often there is some ''hidden'' format. For instance, many embedded CPUs may have crypto-graphic offsets with-in a binary that are used to find digest, file sizes, etc. Another instance is some nRF chipsets with ROM code that does RF base band and application code that is loaded.
This brings up two related topics.
The difference between these tasks is when they occur; when building or at run-time. For instance, many binaries have 'init data' sections. This is static variables that have a 'boot' value. They are copied from a ROM/Flash section to the live RAM location. This is in essence a small loader.
An SREC and iHex are in-between an ELF and a binary. Data is tagged with address and you can have 'gaps' in data. This can be a benefit if code/data are separate and/or you have different memory targets. These concepts will seem foreign to anyone who doesn not do 'embedded' or 'firmware' programming.
The ELF file has a rich format for relocation and other notations (such as debug, frame layout, etc). These tables maybe needed at runtime. For instance, you can/should take '.exidx' and '.extab' data from an ELF into a binary, if you want to perform stack tracing at run time (in a binary image). You must arrange for your run time to use this information to trace a stack. In fact, most toolsets will allow you to put any/all ELF information in a binary.
Some of the elf information/sections does not make sense when loading. When different object files are processed (partial/full link), there are many 'references' that are resolved. If you have an OS, then it may resolve some of the references at load time (by a loader like ld.so) or use them for other purposes. As the compile phase often produces ELF objects, for later processing, many OS's will also have a loader that knows and understand the ELF format.
People with an ELF loader might produce a binary to compress or encrypt. This binary will then be included in an ELF file and a small 'loader' section will perform the decompress or decrypt step.
The benefit of ELF is, it is a documented format. So, with some work a new toolset can work with an OS that supports ELF. You have more interoperability and tool choices.
For a binary, it can support anything that ELF does, but you have to make all the infrastructure yourself and most people don't like re-inventing the wheel.
我只想在这里纠正一点。 ELF 文件是由链接器而不是编译器生成的。
从源代码文件生成目标文件 (*.o) 后，编译器任务结束。链接器将所有 .o 文件链接在一起并生成 ELF。
I just want to correct a point here. ELF file is produced by the Linker, not the compiler.
The Compiler mission ends after producing the object files (*.o) out of the source code files. Linker links all .o files together and produces the ELF.