u-boot .lds檔案詳解(未知平台)

來源:互聯網
上載者:User

轉自:jjavaa

對於.lds檔案,決定一個可執行程式的各個段的儲存位置,以及入口地址,這也是連結定位的作用。這裡以u-boot的lds為例說明uboot的連結過程。

首先看一下GNU官方網站上對.lds檔案形式的完整描述:
SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : AT ( ldadr )
  { contents } >region :phdr =fill
...
}
secname和contents是必須的,前者用來命名這個段,後者用來確定代碼中的什麼部分放在這個段,以下是對這個描述中的一些關鍵字的解釋。
1、secname:段名
2、contents:決定哪些內容放在本段,可以是整個目標檔案,也可以是目標檔案中的某段(程式碼片段、資料區段等)
3、start:是段的重定位地址,本段串連(運行)的地址,如果代碼中有位置無關指令,程式運行時這個段必須放在這個地址上。start可以用任意一種描述地址的符號來描述。
4、AT(ldadr):定義本段儲存(載入)的地址,如果不使用這個選項,則載入地址等於運行地址,通過這個選項可以控制各段分別儲存於輸出檔案中不同的位置。
例:
/* nand.lds */
SECTIONS {
firtst 0x00000000 : { head.o init.o }
second 0x30000000 : AT(4096) { main.o }
}
    以上,head.o放在0x00000000地址開始處,init.o放在head.o後面,他們的運行地址也是0x00000000,即串連和儲存地址相同(沒有AT指定);main.o放在4096(0x1000,是AT指定的,儲存地址)開始處,但它的運行地址在0x30000000,運行之前需要從0x1000(載入地址處)複製到0x30000000(運行地址處),此過程也就需要讀取 flash,把程式拷貝到相應位置才能運行。這就是儲存地址和運行地址的不同,稱為載入時域和運行時域,可以在.lds串連指令檔中分別指定。
編寫好的.lds檔案,在用arm-linux-ld串連命令時帶-Tfilename來調用執行,如
arm-linux-ld –Tnand.lds x.o y.o –o xy.o。也用-Ttext參數直接指定串連地址,如
arm-linux-ld –Ttext 0x30000000 x.o y.o –o xy.o。
既然程式有了兩種地址,就涉及到一些跳轉指令的區別。
ARM彙編中,常有兩種跳轉方法:b跳轉指令、ldr指令向PC賦值。
要特別注意這兩條指令的意思:
(1)       b step:b跳轉指令是相對跳轉,依賴當前PC的值,位移量是通過該指令本身的    bit[23:0]算出來的,這使得使用b指令的程式不依賴於要跳到的代碼的位置,只看指令本身。
(2)       ldr pc, =step :該指令是一個偽指令編譯後會產生以下代碼:
        ldr pc, 0x30008000
        <0x30008000>
                        step
    是從記憶體中的某個位置(step)讀出資料並賦給PC,同樣依賴當前PC的值,但是位移量是step的串連地址(運行時的地址),所以可以用它實現從Flash到RAM的程式跳轉。
(3) 此外,有必要回味一下adr偽指令,U-boot中那段relocate代碼就是通過adr實現當前程式是在RAM中還是flash中:
         relocate:                                   /* 把U-Boot重新置放到RAM */
              adr r0, _start                       /* r0是代碼的當前位置 */
/* adr偽指令,彙編器自動通過當前PC的值算出這條指令中“_start"的值,執行到_start時PC的值放到r0中:
當此段在flash中執行時r0 = _start = 0;當此段在RAM中執行時_start = _TEXT_BASE(在board/smdk2410/config.mk中指定的值為0x33F80000,即u-boot在把代碼拷貝到RAM中去執行的程式碼片段的開始) */
    ldr r1, _TEXT_BASE                       /* 測試判斷是從Flash啟動,還是RAM */
/* 此句執行的結果r1始終是0x33FF80000,因為此值是連結指定的 */
    cmp r0, r1                                    /* 比較r0和r1,調試的時候不要執行重定位 */
    結合u-boot.lds談談串連指令碼。
OUTPUT_FORMAT("elf32&shy;littlearm", "elf32&shy;littlearm", "elf32&shy;littlearm")
                                                        ;指定輸出可執行檔是elf格式,32位ARM指令,小端
OUTPUT_ARCH(arm)
                                                        ;指定輸出可執行檔的平台為ARM
ENTRY(_start)
                                                        ;指定輸出可執行檔的起始程式碼段為_start.
SECTIONS
{
        . = 0x00000000             ; 定位當前地址為0地址
        . = ALIGN(4)                 ; 代碼以4位元組對齊
        .text :                                       ;指定程式碼片段
        {
           cpu/arm920t/start.o (.text)  ; 代碼的第一個代碼部分
          *(.text)                        ;其它代碼部分
        }
        . = ALIGN(4)
        .rodata : { *(.rodata) }         ;指定唯讀資料區段
        . = ALIGN(4);
        .data : { *(.data) }             ;指定讀/寫資料區段
        . = ALIGN(4);
        .got : { *(.got) }                        ;指定got段, got段式是uboot自訂的一個段, 非標準段
         __u_boot_cmd_start = .          ;把__u_boot_cmd_start賦值為當前位置, 即起始位置
        .u_boot_cmd : { *(.u_boot_cmd) }          ;指定u_boot_cmd段, uboot把所有的uboot命令放在該段.
         __u_boot_cmd_end = .                          ;把__u_boot_cmd_end賦值為當前位置,即結束位置
        . = ALIGN(4);
         __bss_start = .                                       ; 把__bss_start賦值為當前位置,即bss段的開始位置
        .bss : { *(.bss) }                        ; 指定bss段
         _end = .                                  ; 把_end賦值為當前位置,即bss段的結束位置
}網上大部分u-boot.lds檔案的分析大部分都是千遍一律,例如下面就是本人在網上找到的關於u-boot.lds的資料。

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

/*指定輸出可執行檔是elf格式,32位ARM指令,小端*/
OUTPUT_ARCH(arm)

/*指定輸出可執行檔的平台為ARM*/
ENTRY(_start)

/*指定輸出可執行檔的起始程式碼段為_start*/
SECTIONS
{

/*指定可執行image檔案的全域進入點,通常這個地址都放在ROM(flash)0x0位置。必須使編譯器知道這個地址,通常都是修改此處來完成*/
 . = 0x00000000;/*;從0x0位置開始*/
 . = ALIGN(4);/*代碼以4位元組對齊*/
 .text :
 {
  cpu/arm920t/start.o (.text)

    /*代碼的第一個代碼部分*/  
  *(.text)

  /*下面依次為各個text段函數*/
 }
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }

 /*指定唯讀資料區段*/
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 .data : { *(.data) }
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 .got : { *(.got) }

/*指定got段, got段是uboot自訂的一個段, 非標準段*/
 . = .;
 __u_boot_cmd_start = .;

/*把__u_boot_cmd_start賦值為當前位置, 即起始位置*/
 .u_boot_cmd : { *(.u_boot_cmd) }

 /*指定u_boot_cmd段, uboot把所有的uboot命令放在該段.*/
 __u_boot_cmd_end = .;

 /*把__u_boot_cmd_end賦值為當前位置,即結束位置*/
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 __bss_start = .;

 /*把__bss_start賦值為當前位置,即bss段的開始位置*/
 .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }

/*指定bss段,告訴載入器不要載入這個段*/
 __bss_end = .;

/*把_end賦值為當前位置,即bss段的結束位置*/
}

看完上面的解析思路本來應該是很清晰的,於是乎編譯u-boot,查看一下System.map,

30100000 T _start

30100020 t _undefined_instruction

30100024 t _software_interrupt

30100028 t _prefetch_abort

3010002c t _data_abort

30100030 t _not_used

30100034 t _irq

30100038 t _fiq

發現 _start 的連結地址不是u-boot.lds中.text 的當前地址0x00000000,而是0x30100000,這就產生很多疑問了:

(1)     為什麼u-boot.lds指定的 .text 的首地址不起作用?

(2)     0x30100000是什麼地址,由誰指定.text的首地址是0x30100000的呢?

(3)     假如有其他動作改變了 .text 的首地址,那麼該動作跟u-boot.lds的優先順序又是怎麼決定的呢?

其實這三個問題都在Makefile的LDFLAGS 變數和u-boot.lds 中找到答案。我們不妨試著修改一下u-boot.lds,把u-boot.lds修改成如下(紅色字型部分為修改過部分):

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

/*指定輸出可執行檔是elf格式,32位ARM指令,小端*/
OUTPUT_ARCH(arm)

/*指定輸出可執行檔的平台為ARM*/
ENTRY(_start)

/*指定輸出可執行檔的起始程式碼段為_start*/
SECTIONS
{

/*指定可執行image檔案的全域進入點,通常這個地址都放在ROM(flash)0x0位置。必須使編譯器知道這個地址,通常都是修改此處來完成*/
 . = 0x30000000;/*;從0x0位置開始*/
 . = ALIGN(4);/*代碼以4位元組對齊*/

.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
 . = ALIGN(4);

/*代碼以4位元組對齊*/

 .text :
 {
  cpu/arm920t/start.o (.text)

    /*代碼的第一個代碼部分*/  
  *(.text)

  /*下面依次為各個text段函數*/
 }

 /*指定唯讀資料區段*/
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 .data : { *(.data) }
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 .got : { *(.got) }

/*指定got段, got段是uboot自訂的一個段, 非標準段*/
 . = .;
 __u_boot_cmd_start = .;

/*把__u_boot_cmd_start賦值為當前位置, 即起始位置*/
 .u_boot_cmd : { *(.u_boot_cmd) }

 /*指定u_boot_cmd段, uboot把所有的uboot命令放在該段.*/
 __u_boot_cmd_end = .;

 /*把__u_boot_cmd_end賦值為當前位置,即結束位置*/
 . = ALIGN(4);

/*代碼以4位元組對齊*/
 __bss_start = .;

 /*把__bss_start賦值為當前位置,即bss段的開始位置*/
 .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }

/*指定bss段,告訴載入器不要載入這個段*/
 __bss_end = .;

/*把_end賦值為當前位置,即bss段的結束位置*/
}

上面對u-boot.lds主要做了兩點修改

(1)     把0x00000000 改成 0x30000000。

(2)     把 .text 和 .rodata 存放的地址調換了位置。

重新編譯 u-boot, 查看System.map

30000000 R version_string

30000028 r C.27.2365

30100000 T _start

30100020 t _undefined_instruction

從上面的System.map部分內容可以看出:

(1)     u-boot.lds設定的地址(0x00000000或0x30000000)是有效。

(2)     .text的地址仍然是30100000

跟著我們查看Makefile中的LDFLAGS變數,發現一條指令

LDFLAGS += -Ttext $(TEXT_BASE)  其中TEXT_BASE 是在u-boot根目錄的board檔案夾的對應的開發板名字的子目錄下的config.mk檔案中定義的

TEXT_BASE = 0x30100000

看到這裡我們應該明白為什麼_start,也就是.text的首地址總是等於0x30100000了,在串連的時候ld命令會把參數-Ttext指定的地址賦給.text,所以.text在u-boot.lds中的預設地址(當前地址)不起作用了

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.