What does the object file contain?

At different stages of compilation in C or C ++, I know that an object file is created (i.e. the file any_name.o). What does this .o file contain? I can not open it, because it is a binary file.

Can anyone help me out? Is the contents of the object file mostly dependent on the compiler we use on Unix?

+42
c ++ c compilation
Jun 15 '10 at 13:33
source share
8 answers

Object files can contain a bunch of things: basically this is a few or the whole list below:

  • Character Names
  • Compiled code
  • Permanent data, for example. strings
  • Import - what characters the compiled code refers to (corrected by the linker)
  • Export - what symbols the object file provides for OTHER object files.

The component turns a bunch of object files into an executable file, matching all import and export and changing the compiled code so that the called functions are called.

+44
Jun 15 '10 at 13:38
source share

There are several standardized formats (COFF, ELF on Unix), mainly variants of the same formats that are used for executable files, but some information is missing. This missing information will be filled in when linking.

The file formats of objects basically contain the same information:

  • compiled binary (for the target processor)
  • static data used by this part of the program (for example, constant strings, etc.). You can make a more precise distinction between BSS (exported data) and text (data that will not be changed by the program). But this is mainly important for the compiler and linker. Please note that, like binary code, the data also depends on the target (big-endian, little-endian, 32bits, 64bits).
  • symbol tables exported by this part of the program (mainly function entry points)
  • external symbol tables used by this part of the program

When the objects are connected to each other, the parts of the code that refer to external characters will be replaced by the actual values ​​(well, this is still simplified, there is the last part that will be executed at boot time when the program starts, but that’s the idea).

An object file may also contain more symbol information, which is strictly necessary to allow import and export (useful for debugging). This information can be deleted using the strip command.

+7
Jun 15 '10 at 13:41
source share

Read the wiki page first. You can use objdump to examine such a file :)

+5
Jun 15 '10 at 13:35
source share

Use the file command for such things. This is an ELF object file in a modern Linux system. For example. if compiled for 32-bit x86.

ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped 

In contrast, a dynamically linked executable might look like this:

 ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped 

To see headings, including section names, you can use:

 objdump -x any_name.o 

For dismantling:

 objdump -d any_name.o 
+3
Jun 15 '10 at 13:34 on
source share

An object file is a compiled source.

This means that this is machine code that depends on the target platform (you can compile for Unix on Windows if you really want to), and the compiler used. Different compilers will produce different machine codes from the same source file.

+3
Jun 15 '10 at 13:35
source share

You can open the binaries first! Do not be afraid of this, you only need the right tools! Being binary data, a text editor, of course, is not the right tool; the right tool can be a hex editor or an advanced editor such as emacs, or a tool that instead of just “outputting” bytes in their “hexadecimal” representation and letting you know this particular format alone and “correctly interpret” the data on at some level (for example, GIMP interprets a PNG file as an image and displays it, the PNG analyzer "decomposes" the data in PNG sections, showing you flags in certain bytes, ..., etc.).

In your case, the general answer is that the object file contains your compiled code (and data), as well as all the additional information the linker needs, and ultimately more.

How these informational "organized", and in some cases - in what it means "ultimately more", it depends on the specific format of the object. Some wikipedia links listing some of the features, this , this , this , this ...

Each of them may have its own tools for analyzing content; for example readelf for ELF, objdump for several formats (try objdump -i ) depending on how it was compiled.

+3
Jun 15 '10 at 14:13
source share

The file contains binary data that must be executed via linker to generate an executable file. This is essentially a bunch of machine code instructions with named sections (corresponding to your functions). From wikipedia ' Object File :

In computer science, an object file is an organized collection of individual, named sequences of machine code [edit]. Each sequence, or object, usually contains instructions for the host machine to perform some task, possibly accompanied by relevant data and metadata (for example, moving information, stacking information, comments, program symbols, debugging or profiling information). Typically, the linker is used to generate an executable file or library by combining parts of the files object.

+1
Jun 15 '10 at 13:37
source share

In the GNU compilation environment, you can watch with objdump both in the executable file and in the object file.

As you can see, the object contains only the code of functions declared / referenced in the compiled file (the file contains only the main function with scanf and printf).

 $ objdump -t scanf_sample.o scanf_sample.o: file format pe-i386 SYMBOL TABLE: [ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 scanf_sample.c File [ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _main [ 3](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text AUX scnlen 0x91 nreloc 9 nlnno 0 [ 5](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data AUX scnlen 0x0 nreloc 0 nlnno 0 [ 7](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss AUX scnlen 0x0 nreloc 0 nlnno 0 [ 9](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata AUX scnlen 0x54 nreloc 0 nlnno 0 [ 11](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 ___main AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0 [ 13](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __alloca [ 14](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _memset [ 15](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _scanf [ 16](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _printf 

If you use objdump for the executable, you can see a lot more functions (besides those that are inside the object). This proves that the object file contains only functions defined in the source file with links to other functions. These links will be resolved at the linking stage.

Read more on link , compilation and objects .

+1
Jun 15 '10 at 13:50
source share



All Articles