2. 程式人生 > >linux核心之elf格式

linux核心之elf格式

阿新 • • 發佈：2019-02-14

圖 18.1. ELF檔案


2.2.1目標檔案

下面用readelf工具讀出目標檔案max.o的ELF Header和Section Header Table，然後我們逐段分析。

$ readelf -a max.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          200 (bytes into file) //從檔案地址200（0xc8）開始，
 // 每個Section Header佔40位元組，共40*8=320位元組，到檔案地址0x207結束
 
。
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
 Number of section headers: 8
  Section header string table index: 5 2.2.2 section頭 Section Headers:
 


  [Nr] Name              Type            Addr                       Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL                 00000000             000000 000000 00      0   0  0
  [ 1] .text             PROGBITS     00000000             000034 00002a 00  AX  0   0  4
  [ 2] .rel.text         REL                00000000             0002b0 000010 08      6   1  4
  [ 3] .data             PROGBITS    00000000             000060 000038 00  WA  0   0  4
  [ 4] .bss              NOBITS         00000000             000098 000000 00  WA  0   0  4
  [ 5] .shstrtab         STRTAB       00000000            000098 000030 00      0   0  1
  [ 6] .symtab           SYMTAB      00000000             000208 000080 10      7   7  4
  [ 7] .strtab           STRTAB          00000000           000288 000028 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no program headers in this file.

注：從Section Header中讀出各Section的描述資訊，

其中.text和.data是我們在彙編程式中宣告的Section，而其它Section是彙編器自動新增的。

Addr是這些段載入到記憶體中的地址（我們講過程式中的地址都是虛擬地址），載入地址要在連結時填寫，現在空缺，所以是全0。

Off和Size列指出了各Section的起始檔案地址和長度。比如.data段從檔案地址0x60開始，一共0x38個位元組，回去翻一下程式，.data段定義了14個4位元組的整數，一共是56個位元組，也就是0x38。根據以上資訊可以描繪出整個目標檔案的佈局。

表 18.1. 目標檔案的佈局

起始檔案地址 Section或Header
0 ELF Header
0x34 .text
0x60 .data
0x98 .bss（此段為空）
0x98 .shstrtab
0xc8 Section Header Table
0x208 .symtab
0x288 .strtab
0x2b0 .rel.text 
這個檔案不大，我們直接用hexdump工具把目標檔案的位元組全部打印出來看。
》hexdump -C max.o
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  01 00 03 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  c8 00 00 00 00 00 00 00  34 00 00 00 00 00 28 00  |........4.....(.|
00000030  08 00 05 00 bf 00 00 00  00 8b 04 bd 00 00 00 00  |................|
00000040  89 c3 83 f8 00 74 10 47  8b 04 bd 00 00 00 00 39  |.....t.G.......9|
00000050  d8 7e ef 89 c3 eb eb b8  01 00 00 00 cd 80 00 00  |.~..............|
00000060  03 00 00 00 43 00 00 00  22 00 00 00 de 00 00 00  |....C...".......|
00000070  2d 00 00 00 4b 00 00 00  36 00 00 00 22 00 00 00  |-...K...6..."...|
00000080  2c 00 00 00 21 00 00 00  16 00 00 00 0b 00 00 00  |,...!...........|
00000090  42 00 00 00 00 00 00 00  00 2e 73 79 6d 74 61 62  |B.........symtab|
000000a0  00 2e 73 74 72 74 61 62  00 2e 73 68 73 74 72 74  |..strtab..shstrt|
000000b0  61 62 00 2e 72 65 6c 2e  74 65 78 74 00 2e 64 61  |ab..rel.text..da|
000000c0  74 61 00 2e 62 73 73 00  00 00 00 00 00 00 00 00  |ta..bss.........|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

我們繼續分析readelf輸出的最後一部分，是從.rel.text和.symtab這兩個Section中讀出的資訊。

...
Relocation section '.rel.text' at offset 0x2b0 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000008  00000201 R_386_32          00000000   .data
00000017  00000201 R_386_32          00000000   .data

There are no unwind sections in this file.

Symbol table '.symtab' contains 8 entries:
   Num:              Value      Size     Type    Bind            Vis      Ndx Name
     0:             00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1:             00000000     0 SECTION LOCAL  DEFAULT    1
     2:             00000000     0 SECTION LOCAL  DEFAULT    3
     3:            00000000     0 SECTION LOCAL  DEFAULT    4
     4:            00000000     0 NOTYPE  LOCAL  DEFAULT    3     data_items
     5:            0000000e     0 NOTYPE  LOCAL  DEFAULT    1     start_loop
     6:          00000023      0 NOTYPE  LOCAL  DEFAULT    1     loop_exit
     7:         00000000       0 NOTYPE  GLOBAL DEFAULT  1   _start

No version information found in this file.

注： .rel.text告訴連結器指令中的哪些地方需要做重定位，在下一小節詳細討論。 .symtab是符號表。Ndx列是每個符號所在的Section編號，
例如符號data_items在第3個Section裡（也就是.data段），
各Section的編號見Section Header Table。
Value列是每個符號所代表的地址，在目標檔案中，符號地址都是相對於該符號所在Section的相對地址，
比如data_items位於.data段的開頭，所以地址是0，_start位於.text段的開頭，所以地址也是0，
但是start_loop和loop_exit相對於.text段的地址就不是0了。
從Bind這一列可以看出_start這個符號是GLOBAL的，而其它符號是LOCAL的，
GLOBAL符號是在彙編程式中用.globl指示宣告過的符號。

2.2.3

現在剩下.text段沒有分析，objdump工具可以把程式中的機器指令反彙編（Disassemble），那麼反彙編的結果是否跟原來寫的彙編程式碼一模一樣呢？我們對比分析一下。

$ objdump -d max.o

max.o:     file format elf32-i386

Disassembly of section .text:

00000000 <_start>:
   0:	bf 00 00 00 00       	mov    $0x0,%edi
   5:	8b 04 bd 00 00 00 00 	mov    0x0(,%edi,4),%eax
   c:	89 c3                	mov    %eax,%ebx

0000000e <start_loop>:
   e:	83 f8 00             	cmp    $0x0,%eax
  11:	74 10                	je     23 <loop_exit>
  13:	47                   	inc    %edi
  14:	8b 04 bd 00 00 00 00 	mov    0x0(,%edi,4),%eax
  1b:	39 d8                	cmp    %ebx,%eax
  1d:	7e ef                	jle    e <start_loop>
  1f:	89 c3                	mov    %eax,%ebx
  21:	eb eb                	jmp    e <start_loop>

00000023 <loop_exit>:
  23:	b8 01 00 00 00       	mov    $0x1,%eax
  28:	cd 80                	int    $0x80

2.3. 可執行檔案

現在我們按上一節的步驟分析可執行檔案max，看看連結器都做了什麼改動。

$ readelf -a max
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048074
  Start of program headers:          52 (bytes into file)
  Start of section headers:          256 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         6
  Section header string table index: 3

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        08048074 000074 00002a 00  AX  0   0  4
  [ 2] .data             PROGBITS        080490a0 0000a0 000038 00  WA  0   0  4
  [ 3] .shstrtab         STRTAB          00000000 0000d8 000027 00      0   0  1
  [ 4] .symtab           SYMTAB          00000000 0001f0 0000a0 10      5   6  4
  [ 5] .strtab           STRTAB          00000000 000290 000040 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0x0009e 0x0009e R E 0x1000
  LOAD           0x0000a0 0x080490a0 0x080490a0 0x00038 0x00038 RW  0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data 

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

Symbol table '.symtab' contains 10 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 08048074     0 SECTION LOCAL  DEFAULT    1
     2: 080490a0     0 SECTION LOCAL  DEFAULT    2
     3: 080490a0     0 NOTYPE  LOCAL  DEFAULT    2 data_items
     4: 08048082     0 NOTYPE  LOCAL  DEFAULT    1 start_loop
     5: 08048097     0 NOTYPE  LOCAL  DEFAULT    1 loop_exit
     6: 08048074     0 NOTYPE  GLOBAL DEFAULT    1 _start
     7: 080490d8     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
     8: 080490d8     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
     9: 080490d8     0 NOTYPE  GLOBAL DEFAULT  ABS _end

No version information found in this file.

在ELF Header中，Type改成了EXEC，由目標檔案變成可執行檔案了，Entry point address改成了0x8048074（這是_start符號的地址），還可以看出，多了兩個Program Header，少了兩個Section Header。

在Section Header Table中，.text和.data段的載入地址分別改成了0x08048074和0x080490a0。.bss段沒有用到，所以被刪掉了。.rel.text段就是用於連結過程的，做完連結就沒用了，所以也刪掉了。

多出來的Program Header Table描述了兩個Segment的資訊。.text段和前面的ELF Header、Program Header Table一起組成一個Segment（FileSiz指出總長度是0x9e），.data段組成另一個Segment（總長度是0x38）。VirtAddr列指出第一個Segment載入到虛擬地址0x08048000（注意在x86平臺上後面的PhysAddr列是沒有意義的，並不代表實際的實體地址），第二個Segment載入到地址0x080490a0。Flg列指出第一個Segment的訪問許可權是可讀可執行，第二個Segment的訪問許可權是可讀可寫。最後一列Align的值0x1000（4K）是x86平臺的記憶體頁面大小。在載入時檔案也要按記憶體頁面大小分成若干頁，檔案中的一頁對應記憶體中的一頁，對應關係如下圖所示。


這個可執行檔案很小，總共也不超過一頁大小，但是兩個Segment必須載入到記憶體中兩個不同的頁面，因為MMU的許可權保護機制是以頁為單位的，一個頁面只能設定一種許可權。此外還規定每個Segment在檔案頁面內偏移多少載入到記憶體頁面仍然要偏移多少，比如第二個Segment在檔案中的偏移是0xa0，在記憶體頁面0x08049000中的偏移仍然是0xa0，所以從0x080490a0開始，這樣規定是為了簡化連結器和載入器的實現。從上圖也可以看出.text段的載入地址應該是0x08048074，_start符號位於.text段的開頭，所以_start符號的地址也是0x08048074，從符號表中可以驗證這一點。

原來目標檔案符號表中的Value都是相對地址，現在都改成絕對地址了。此外還多了三個符號__bss_start、_edata和_end，這些符號在連結指令碼中定義，被連結器新增到可執行檔案中。

再看一下反彙編的結果：

$ objdump -d max

max:     file format elf32-i386

Disassembly of section .text:

08048074 <_start>:
 8048074:	bf 00 00 00 00       	mov    $0x0,%edi
 8048079:	8b 04 bd a0 90 04 08 	mov    0x80490a0(,%edi,4),%eax
 8048080:	89 c3                	mov    %eax,%ebx

08048082 <start_loop>:
 8048082:	83 f8 00             	cmp    $0x0,%eax
 8048085:	74 10                	je     8048097 <loop_exit>
 8048087:	47                   	inc    %edi
 8048088:	8b 04 bd a0 90 04 08 	mov    0x80490a0(,%edi,4),%eax
 804808f:	39 d8                	cmp    %ebx,%eax
 8048091:	7e ef                	jle    8048082 <start_loop>
 8048093:	89 c3                	mov    %eax,%ebx
 8048095:	eb eb                	jmp    8048082 <start_loop>

08048097 <loop_exit>:
 8048097:	b8 01 00 00 00       	mov    $0x1,%eax
 804809c:	cd 80                	int    $0x80

指令中的相對地址都改成絕對地址了。我們仔細檢查一下改了哪些地方。首先看跳轉指令，原來目標檔案的指令是這樣：

...
  11:	74 10                	je     23 <loop_exit>
...
  1d:	7e ef                	jle    e <start_loop>
...
  21:	eb eb                	jmp    e <start_loop>
...

現在改成了這樣：

...
 8048085:	74 10                	je     8048097 <loop_exit>
...
 8048091:	7e ef                	jle    8048082 <start_loop>
...
 8048095:	eb eb                	jmp    8048082 <start_loop>
...

改了嗎？其實只是反彙編的結果不同了，指令的機器碼根本沒變。為什麼不用改指令就能跳轉到新的地址呢？因為跳轉指令中指定的是相對於當前指令向前或向後跳多少位元組，而不是指定一個完整的記憶體地址，記憶體地址有32位，這些跳轉指令只有16位，顯然也不可能指定一個完整的記憶體地址，這稱為相對跳轉。這種相對跳轉指令只有16位，只能在當前指令前後的一個小範圍內跳轉，不可能跳得太遠，也有的跳轉指令指定一個完整的記憶體地址，可以跳到任何地方，這稱絕對跳轉.

再看記憶體訪問指令，原來目標檔案的指令是這樣：

...
   5:	8b 04 bd 00 00 00 00 	mov    0x0(,%edi,4),%eax
...
  14:	8b 04 bd 00 00 00 00 	mov    0x0(,%edi,4),%eax
...

現在改成了這樣：

...
 8048079:	8b 04 bd a0 90 04 08 	mov    0x80490a0(,%edi,4),%eax
...
 8048088:	8b 04 bd a0 90 04 08 	mov    0x80490a0(,%edi,4),%eax
...

指令中的地址原本是0x00000000，現在改成了0x080490a0（注意是小端位元組序）。那麼連結器怎麼知道要改這兩處呢？是根據目標檔案中的.rel.text段提供的重定位資訊來改的：

...
Relocation section '.rel.text' at offset 0x2b0 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000008  00000201 R_386_32          00000000   .data
00000017  00000201 R_386_32          00000000   .data
...

第一列Offset的值就是.text段需要改的地方，在.text段中的相對地址是8和0x17，正是這兩條指令中00 00 00 00的位置。

相關推薦

linux核心之elf格式

圖 18.1. ELF檔案 2.2.1目標檔案 下面用readelf工具讀出目標檔案max.o的ELF Header和Section Header Table，然後我們逐段分析。 $ readelf -a max.o ELF Header: Magic: 7f 45 4c 46 01

Linux核心之vmlinux與vmlinuz

因為是初次系統的學習Linux核心，過程中遇到了一些常常出現的名詞。似曾相識，但對他們的含義又不是非常清楚。因此，將搜尋到的內容進行一下彙總。 1.vmlinux   vmlinux是一個包括linux kernel的靜態連結的可執行檔案。檔案型別是l

linux核心之class介紹(三)

前兩節介紹了class,device結構體的成員,在這一節主要介紹class和device的關鍵函式. 1.classes_init() 系統呼叫路徑: start_kernel()->>rest_init()->>kernel_init()->>do_b

linux核心之class介紹(二)

在最底層,在linux系統裡每個裝置由一個device結構體表示.device結構體包含了裝置模型核心需要的資訊 大部分subsystem,還會增加額外的資訊.因此很少單獨由一個device表示一個裝置;而是像kobject一樣嵌入到 一個更大的結構體來表示一個裝置. device結構體定義

linux核心之class介紹(一)

class的概念 class是裝置的更高層檢視,抽象出了底層的實現細節.驅動程式會區分SCSI硬碟和ATA硬碟,但在class層他們都是 硬碟.classes幫助使用者空間只需要知道這些是什麼裝置,而不需要關心他們是怎麼連線和工作的.(A class is a higher-level vi

linux核心之klist連結串列

klist介面提供了兩個封裝了list_head的結構體,連結串列頭klist和連結串列節點klist_node 對於結構體klist包含一個spinlock來提供訪問保護.klist_node包含一個klist指標指向 歸屬的klist和kref引用計數器指示該節點的引用次數. 連結串列頭

linux核心之spin lock

轉自：http://www.wowotech.net/kernel_synchronization/spinlock.html 一、前言 在linux kernel的實現中，經常會遇到這樣的場景：共享資料被中斷上下文和程序上下文訪問，該如何保護呢？如果只有程序上下文的訪問，那麼可以考慮使用s

linux 核心之completion

    如果核心中一個任務需要發出訊號通知另外一個任務發生了某個特定事件，使用完成量completion是兩個任得以同步的最簡單方法。當任務1需要執行某些工作時，需要等待任務2完成特定操作才能繼續執行，那麼任務1就會阻塞等待，當任務2的特定操作執行完成之後，通過complet

linux核心之USB驅動分析

第一部分  USB驅動程式框架 　　app: 　　------------------------------------------- 　　USB裝置驅動程式 　　 // 知道資料含義　　核心 -------------------------------------- 　　USB匯流

Linux核心之GDB基本除錯方法

Oops[#1]:Cpu 0$ 0   : 00000000 10008d00 00000000 ffffffea$ 4   : fffffdfd 10008d01 00000001 00000000$ 8   : 00000000 7fed2e40 00001cb2 00000b3b$12   : 0003

（Linux核心）printk 格式說明

printk的格式說明符 :  int %d 或者 %x( 注： %d 是十進位制， %x 是十六進位制 )  u32 或者 unsigned int %u 或者 %x  long %ld 或者 %l

Linux核心之禁止中斷和禁止核心搶佔

禁止中斷指的是Linux核心停工了一組介面用於操作機器上的中斷狀態。這些介面為我們提供了能夠禁止當前處理器的中斷系統，或者遮蔽掉整個機器的一條中斷線的能力。通過禁止中斷，可以確保某個中斷處理程式不會搶佔當前的程式碼。控制中斷系統在Linux的實現有很多，以local_irq

linux核心之offset_of和container_of理解

無意間在騰訊課堂上看到有個老師講解linux核心連結串列，開始就講這兩個巨集。 這篇文章主要是為了記錄對這兩個巨集的使用和理解。 測試環境: win10 64bit 家庭版 gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

linux核心之排程演算法（二）

  上層排程，linux排程的核心函式為schedule，schedule函式封裝了核心排程的框架。細節實現上呼叫具體的排程類中的函式實現。schedule函式主要流程為： 1，將當前程序從相應的執行佇列中刪除； 2，計算和更新排程實體和程序的相關排程資訊； 3，將當前進重

linux核心之程序管理詳解

1、程序描述符 （1）程序與執行緒          程序是處於執行期的程式以及相關資源的總稱。執行緒在linux上稱為輕量級程序，沒有獨立的地址空間，一個程序下的所有執行緒共享地址空間、檔案系統資源、檔案描述符、訊號處理程式等。 （2）程序描述符task_struct

Linux核心之mmc子系統-sdio

現在的Linux核心中，mmc不僅是一個驅動，而是一個子系統。這裡通過分析Linux3.2.0核心，結合TI的arm335x平臺及omap_hsmmcd host分析下mmc子系統，重點關注sdio及架構在其上的具體sdio IP驅動實現。 1.      Genera

linux核心之chdir分析

今天我們看一些在linux系統裡邊經常使用的cd命令對應的核心實現，就是sys_chdir函式的實現。 sys_chdir函式在fs/open.c裡，定義如下asmlinkage long sys_c

Linux核心之定時器詳解

static struct pin_desc *irq_pd; /* 鍵值: 按下時, 0x01, 0x02, 0x03, 0x04 */ /* 鍵值: 鬆開時, 0x81, 0x82, 0x83, 0x84 */ static unsigned char key_val; struct pin_desc{u

Linux核心之程序排程

一些概念 　　排程程式負責決定哪個程序投入執行，何時執行及執行多長時間。程序排程程式就是在可執行態程序之間分配有限的處理器時間資源的核心子系統。 多工系統可分為兩類：非搶佔式多工和搶佔式多工。Linux提供了搶佔式多工。 I/O消耗型程序就是大部分時間用來

Linux核心之 核心同步

上文我們介紹過程序排程，Linux核心從2.6版本開始支援核心搶佔，所以核心很多程式碼也需要同步保護。   一、同步介紹 1、臨界區與競爭條件 所謂臨界區（critical regions）就是訪問和操作共享資料的程式碼段。為了避免在臨界區中併發訪問，程式設計者必須保證這些程式碼原子地執行——也就是