Tại sao GCC pad hoạt động với NOP?

Question 1

Tôi đã làm việc với C một thời gian ngắn và gần đây đã bắt đầu tham gia vào ASM. Khi tôi biên dịch một chương trình:

int main(void)
  {
  int a = 0;
  a += 1;
  return 0;
  }

Quá trình gỡ bỏ objdump có mã, nhưng không đạt sau lần sửa lại:

...
08048394 <main>:
 8048394:       55                      push   %ebp
 8048395:       89 e5                   mov    %esp,%ebp
 8048397:       83 ec 10                sub    $0x10,%esp
 804839a:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)
 80483a1:       83 45 fc 01             addl   $0x1,-0x4(%ebp)
 80483a5:       b8 00 00 00 00          mov    $0x0,%eax
 80483aa:       c9                      leave  
 80483ab:       c3                      ret    
 80483ac:       90                      nop
 80483ad:       90                      nop
 80483ae:       90                      nop
 80483af:       90                      nop
...

Từ những gì tôi học được, nops không làm gì cả, và vì sau khi ret thậm chí sẽ không được thực hiện.

Câu hỏi của tôi là: tại sao phải bận tâm? ELF (linux-x86) không thể hoạt động với phần .text (+ main) ở bất kỳ kích thước nào?

Tôi đánh giá cao mọi sự giúp đỡ, chỉ cố gắng học hỏi.

Question 2

Trước hết, gcckhông phải lúc nào cũng làm điều này. Phần đệm được điều khiển bởi -falign-functions, được tự động bật bởi -O2và -O3:

-falign-functions
-falign-functions=n

Căn chỉnh phần bắt đầu của các hàm thành lũy thừa tiếp theo của hai lớn hơn n, bỏ qua tối đa nbyte. Ví dụ: -falign-functions=32căn chỉnh các chức năng với ranh giới 32 byte tiếp theo, nhưng -falign-functions=24sẽ căn chỉnh với ranh giới 32 byte tiếp theo chỉ khi điều này có thể được thực hiện bằng cách bỏ qua 23 byte hoặc ít hơn.

-fno-align-functionsvà -falign-functions=1tương đương và có nghĩa là các hàm sẽ không được căn chỉnh.

Một số bộ lắp ráp chỉ hỗ trợ cờ này khi n là lũy thừa của hai; trong trường hợp đó, nó được làm tròn.

Nếu n không được chỉ định hoặc bằng 0, hãy sử dụng mặc định phụ thuộc vào máy.

Được kích hoạt ở mức -O2, -O3.

Có thể có nhiều lý do để làm điều này, nhưng lý do chính trên x86 có lẽ là:

Hầu hết các bộ xử lý tìm nạp các hướng dẫn trong các khối 16 byte hoặc 32 byte được căn chỉnh. Có thể thuận lợi khi căn chỉnh các mục của vòng lặp quan trọng và các mục của chương trình con bằng 16 để giảm thiểu số lượng ranh giới 16 byte trong mã. Ngoài ra, hãy đảm bảo rằng không có ranh giới 16 byte trong vài lệnh đầu tiên sau một mục nhập vòng lặp quan trọng hoặc mục nhập chương trình con.

(Trích từ "Tối ưu hóa chương trình con trong hợp ngữ" của Agner Fog.)

chỉnh sửa: Đây là một ví dụ minh họa padding:

// align.c
int f(void) { return 0; }
int g(void) { return 0; }

Khi được biên dịch bằng gcc 4.4.5 với cài đặt mặc định, tôi nhận được:

align.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <f>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   b8 00 00 00 00          mov    $0x0,%eax
   9:   c9                      leaveq 
   a:   c3                      retq   

000000000000000b <g>:
   b:   55                      push   %rbp
   c:   48 89 e5                mov    %rsp,%rbp
   f:   b8 00 00 00 00          mov    $0x0,%eax
  14:   c9                      leaveq 
  15:   c3                      retq

Chỉ định -falign-functionscho:

align.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <f>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   b8 00 00 00 00          mov    $0x0,%eax
   9:   c9                      leaveq 
   a:   c3                      retq   
   b:   eb 03                   jmp    10 <g>
   d:   90                      nop
   e:   90                      nop
   f:   90                      nop

0000000000000010 <g>:
  10:   55                      push   %rbp
  11:   48 89 e5                mov    %rsp,%rbp
  14:   b8 00 00 00 00          mov    $0x0,%eax
  19:   c9                      leaveq 
  1a:   c3                      retq

Question 3

Điều này được thực hiện để căn chỉnh hàm tiếp theo theo ranh giới 8, 16 hoặc 32 byte.

Từ “Tối ưu hóa chương trình con trong hợp ngữ” của A.Fog:

11.5 Căn chỉnh mã

Hầu hết các bộ vi xử lý tìm nạp mã trong các khối 16 byte hoặc 32 byte được căn chỉnh. Nếu một mục nhập chương trình con quan trọng hoặc nhãn nhảy xảy ra ở gần cuối của khối 16 byte thì bộ xử lý của chúng sẽ chỉ nhận được một vài byte mã hữu ích khi tìm nạp khối mã đó. Nó có thể phải tìm nạp 16 byte tiếp theo trước khi nó có thể giải mã các hướng dẫn đầu tiên sau nhãn. Điều này có thể tránh được bằng cách căn chỉnh các mục nhập chương trình con quan trọng và các mục vòng lặp theo 16.

[...]

Căn chỉnh một mục chương trình con cũng đơn giản như đặt càng nhiều NOP trước mục chương trình con càng tốt để làm cho địa chỉ chia hết cho 8, 16, 32 hoặc 64, như mong muốn.

Question 4

Theo như tôi nhớ, các hướng dẫn được đặt trong cpu và các khối cpu khác nhau (bộ tải, bộ giải mã, v.v.) xử lý các hướng dẫn tiếp theo. Khi các REThướng dẫn đang được thực thi, một số hướng dẫn tiếp theo đã được tải vào đường ống cpu. Đó là một phỏng đoán, nhưng bạn có thể bắt đầu đào tại đây và nếu bạn tìm ra (có thể là số lượng cụ thể NOPan toàn, vui lòng chia sẻ phát hiện của bạn.