Why is my C++ program's assembly output full of .ascii with no assembly code?

user_3208430 0
Viewed 293

I am compiling a C++ file into a static library with CMake and I am modifying the Makefile that CMake generates by adding the -S -fverbose-asm flags to the gcc command to get the assembly output, however the resulting .cpp.s file is filled with .ascii lines with what looks like hexadecimal data, and contains no assembly instructions, like the following:

.ascii  "\346+\274\004@\226\032!n\247<)\212\264\205\377*\204\275\364e"
.ascii  "\314\026\270vi\263\373\327\n\367$\332\035\364N\212\316\254\324"

Does anyone know what might be causing this, and how I can get legible assembly instructions instead?

Version of gcc: 5.4.0

assembly gcc c++
1 Answers

You probably compiled with Link Time Optimization enabled (gcc -flto), which makes "fat" object files that also contain GCC's intermediate representation of the program logic alongside regular asm. (So whole-program optimization can happen at link time, allowing inlining across source files and further optimizations that weren't possible when only a prototype was visible.) Or if you link with a linker that isn't aware of LTO, it will ignore the LTO sections and just use the regular machine-code sections.

https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html

GCC uses .ascii with octal escapes as a somewhat compact (in the asm source) way to emit raw binary in a format the assembler doesn't know about (GIMPLE bytecode).

The alternative would be .byte 12,34,... which is 2 to 4 source bytes per output byte, similar to ASCII with octal which gives 1 to 4. (1 for any byte in the printable ASCII range).

.long 0xabcd220c, 0x... or .quad would come closer to 2 asm source bytes per output byte.

This efficiency consideration is only for the .s temporary file that GCC will feed to as; in the .o the data will be in binary (in an object-file section with a special name). GCC wants a format that's fast to serialize into in GCC, and fast for the assembler to parse and convert back into bytes. Presumably the double-quoted string for .ascii makes parsing simple.

user_2241320
Related