Unix 可执行文件“Exec”，十六进制转储显示 C 代码，而不是汇编

Question

In Os X, I compiled a C program with the command: gcc -o binaryoutName inputfile which I created and then ran a hex dump on the resultant binary "Exec" file. As I understand it, an Exec file is a 'UNIX Executable', which is the UNIX equivalent of an executable file.

When I ran the hex dump using the command xxd -b binary , it returned the ASCII content of the binary, however this ASCII represented the literal C code which i first programmed the .c file in.

Hex dump Extract:

0007c4a: 01101100 01110101 01110011 01101000 00000000 01011111 lush._ 0007c50: 01100110 01101111 01110000 01100101 01101110 00000000 fopen. 0007c56: 01011111 01100110 01110000 01110010 01101001 01101110 _fprin 0007c5c: 01110100 01100110 00000000 01011111 01100111 01100101 tf._ge 0007c62: 01110100 01100011 01101000 01100001 01110010 00000000 tchar. 0007c68: 01011111 01100111 01100101 01110100 01100011 01110111 _getcw 0007c6e: 01100100 00000000 01011111 01100111 01100101 01110100 d._get 0007c74: 01100101 01101110 01110110 00000000 01011111 01101100 env._l 0007c7a: 01101111 01100011 01100001 01101100 01110100 01101001 ocalti 0007c80: 01101101 01100101 00000000 01011111 01101101 01100101 me._me 0007c86: 01101101 01100011 01110000 01111001 00000000 01011111 mcpy._ 0007c8c: 01110000 01110010 01101001 01101110 01110100 01100110 printf 0007c92: 00000000 01011111 01110000 01110101 01110100 01100011 ._putc 0007c98: 01101000 01100001 01110010 00000000 01011111 01110011 har._s 0007c9e: 01100011 01100001 01101110 01100110 00000000 01011111 canf._ 0007ca4: 01110011 01101100 01100101 01100101 01110000 00000000 sleep.

Note that the ASCII translation on the far-right column is extremely similar to the code inside the .c file I initially compiled. This is counter-intuitive as I expected the hex dump to contain the ASCII binary of the Assembly code which the compiler would logically compile it too.

This is a question at the very limits of my understanding of the compilation process and I expect to have a few incorrect details, for which I apologies.

My Question: Why did the hex dump return ASCII for C code instead of Assembly?

Thanks in Advance.

Answer 1

I believe what you saw is the .strtab section (or similar sections) of your executable or object file, which does include string.

For example, for the following C program:

#include <stdio.h>

int main(void)
{
    printf("Hello world!\n");
}

Compiled with the following command:

gcc -Wall -g -std=c11 c00.c

If we hexdump it, we will find something like:

$ xxd a.out
...
00022e0: 0000 0000 0000 0000 0063 7274 7374 7566  .........crtstuf
00022f0: 662e 6300 5f5f 4a43 525f 4c49 5354 5f5f  f.c.__JCR_LIST__
0002300: 0064 6572 6567 6973 7465 725f 746d 5f63  .deregister_tm_c
0002310: 6c6f 6e65 7300 7265 6769 7374 6572 5f74  lones.register_t
0002320: 6d5f 636c 6f6e 6573 005f 5f64 6f5f 676c  m_clones.__do_gl
...

And we can find out the section related information through

$ readelf -WS a.out 
...
  [34] .strtab           STRTAB          0000000000000000 0022e8 000235 00      0   0  1

Notices the offset of .strtab is 0x0022e8, which matches what we saw from the output of xxd .

Answer 2

What you see is not C code but the table of symbols of your executable or object file (symbols that have external linkage property). An object file or executable is formatted (Linux uses ELF standard for example) into different sections: symbol table, global variables, code, etc. For the symbol table, the compiler generates it for different purpose as to generate linkable files or ease debug.

In an executable, these symbols are not mandatory and you can easily remove them with command strip , if you strip an object file you will be unable to link it.

You can show in a more readable form the content of the symbol table with commands like nm .

Read online manual for strip and nm commands, how compilers link object files...