Изменение уровней оптимизации компилятора не меняет скомпилированный двоичный файл

Question

Я использовал arm-linux-gnueabi-gcc toolchain для кросс-компиляции двоичного файла в arm. Странно то, что я не получаю никаких отличий в скомпилированных двоичных файлах, хотя меняю уровень оптимизации. Даже я следовал за этой документацией от 'arm' и взял тот же источник из указанного ниже.

#include <stdio.h>
int main(){

   int x =10, y =20;
   int z;
   z =x+y;
   return 0;

}

Я даже прошел страницу man и думаю, что использую флаг оптимизации правильно. Это именно тот код, который я использую для компиляции.

arm-linux-gnueabi-gcc -O1 -o test test.c 

Тем не менее, производимый объектный файл 'test' не изменяется (размер скомпилированного двоичного файла одинаков) независимо от того, меняю ли я уровень оптимизации как указано в документации по вооружению выше. Что может быть причиной этого? Я что-то здесь не так делаю? Заранее спасибо.

Answer 1

arm-linux-gnueabi-gcc -O0 -c so.c -o so.o
arm-linux-gnueabi-objdump -D so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <main>:
   0:   e52db004    push    {fp}        ; (str fp, [sp, #-4]!)
   4:   e28db000    add fp, sp, #0
   8:   e24dd014    sub sp, sp, #20
   c:   e3a0300a    mov r3, #10
  10:   e50b3010    str r3, [fp, #-16]
  14:   e3a03014    mov r3, #20
  18:   e50b300c    str r3, [fp, #-12]
  1c:   e51b2010    ldr r2, [fp, #-16]
  20:   e51b300c    ldr r3, [fp, #-12]
  24:   e0823003    add r3, r2, r3
  28:   e50b3008    str r3, [fp, #-8]
  2c:   e3a03000    mov r3, #0
  30:   e1a00003    mov r0, r3
  34:   e24bd000    sub sp, fp, #0
  38:   e49db004    pop {fp}        ; (ldr fp, [sp], #4)
  3c:   e12fff1e    bx  lr

arm-linux-gnueabi-gcc -O1 -c so.c -o so.o
arm-linux-gnueabi-objdump -D so.o

so.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <main>:
   0:   e3a00000    mov r0, #0
   4:   e12fff1e    bx  lr

и остальные уровни оптимизации должны давать тот же результат, что и -O1, поскольку это мертвый код, и все это удаляется с помощью простой оптимизации.

Ключ здесь, когда вы говорите " бинарный "Я предполагаю, что вы имеете в виду выходной файл, созданный

arm-linux-gnueabi-gcc -O1 -o test test.c

, в этом" тестовом "файле много всего, для такой простой программы, как эта, практически ничего из этого не является действительным кодом.

Если вы изучите размер объектного файла (см. Выше), а не связанный двоичный файл, вы должны увидеть разницу или использовать двоичный файл arm-what-objcopy -O, и вы "можете" увидеть разницу там это также может быть связано с шумом.

880 байтов для объекта -O0, 824 байта для -O1, но, как вы можете видеть в разборке, в результате оптимизации имеются большие различия в размерах .