2015年4月30日 星期四

Rust Macro 簡介

今天要講的是Rust Macro:
https://doc.rust-lang.org/book/macros.html
Rust 的Macro 是個有趣的功能,能讓你對function 進行擴展,最熟悉的例子大概是println!的macro 擴展。

故事是這樣子的,Rust 有相當嚴格的語法結構:函數要有同樣的特徵,每個overload function 應該存在同樣的trait 中,使用同一個trait 就能為一個function在不同的物件中進行實作。
例如在struct 那篇中:
http://yodalee.blogspot.tw/2015/02/rust-struct-impl-trait.html
我們當範例的struct Car, trait Movable,之後我們要有新的物件,只要再實作(impl) 這個trait ,就可以呼叫該function,編譯時期會對trait 型別進行檢查,但這樣造成的問題是,對不同物件想要有同樣函數實作時,可能會有大量同樣的程式碼需要重寫。

這裡可以取用Macro 來解決,Macro 會在編譯時展開成各種不同版本,可以一一對應到不同的型態上,當然這會讓含有Macro 的code 變得更難懂,因為Macro 如何實作……通常會被隱藏起來,但好好使用可以讓code 變得異常的精簡,算是有好有壞的功能,只要在使用時好好注意即可。

一般最常用到的macro ,大概像vec!,我們可以用
let x: Vec<u32> = vec![1,2,3];
像vec! 這樣的寫法可以初始化一個Vector,這就是利用Macro:
macro_rules! vec {
  ( $( $x:expr ),* ) => {
    {
    let mut temp_vec = Vec::new();
      $(
        temp_vec.push($x);
      )*
    temp_vec
    }
  };
}


每個Macro 都會由 macro_rule! 開頭,定義哪個字詞會觸發這個Macro,之後定義展開規則,這樣vec! 都會依規則展開。
下面會是(match) => ( expansion ) 的形式,編譯時match 會去比對Rust syntax tree,Macro 有一套自己的文法規則:
https://doc.rust-lang.org/reference.html#macros
規則可以像上面這樣虛擬,也可以非常明確,就是要指定某個文字內容,像這樣簡單的Macro 也是會動的:
macro_rules! foo {
  (x) => (3);
  (y) => (4);
}
fn main() {
  println!(“{}”, foo!(x));
}


同時Macro 在展開時也會檢驗是否有不match 的部分,上面的 foo!(z) 會直接回報編譯錯誤;Macro 中可以指定metavariable,以 $ 開頭,並指定它會對應什麼樣的辨識符號,我們這裡指定match rust 的expr,並以x 代稱,外層的 $(...),* 則是類似正規表示法的規則,說明我們可以match 零個或多個內部的符號。

在match 之後,原有的程式碼就會在{}, ()或 [] 內展開成expansion,可以在裡面recursive 的呼叫自己,但無法對變數進行運算,例如recursive 運算的macro rule是不行的:
($x:expr) => RECURSIVE!($x-1)
在vec 中內層的{} 則是要包括多個展開的expression,如果是上面的(x) => (3)就沒這個必要;展開之後,會依照指定的數量 $(...),* ,將內含的metavariable 展開。
所以上面的vec![1,2,3],就會展開成
temp_vec.push(1);
temp_vec.push(2);
temp_vec.push(3);

Rust 這樣的Macro 設計是基於syntax parser 的,所以不必擔心像C macro 會遇到的問題,例如:
#define FIVE(x) 5*x
FIVE(2+3)
如果是Rust 的Macro ,後面的2+3 是會直接parse 成一個expr,因此仍會正常運作,內部的$x 名稱和展開的名稱也不會有任何衝突,不用擔心C Macro字串展開後可能取用到其他變數的問題。
macro_rule! FIVE {
  ($x: expr) => (5*x)
}


在Rust 裡可以進行Macro matcher 的東西非常多,上面的expression 只是當例子,其實這些都可以寫到matcher 裡面,並有對應的要求,這裡就只羅列內容,詳細就請看文件了。
identifier: 變數名稱
path:
ty: 型別名稱,如i32
pat: pattern 像Some(x)
stmt: statement
block: {} 內的內容
item: 函式、struct 的宣告
meta: attributes
tt: token tree

這裡有另一個Macro 的例子:
https://github.com/neykov/armboot/blob/master/libarm/stm32f4xx.rs
這是用Rust 來寫stm32 嵌入式系統,類似標頭檔的內容:
可以看到RCC() 會回傳一個RCCType 的struct,而這個RCCType 會是RCCBase Macro 展開的結果,接著會是另一個Macro,一路展開下去就會得到一個u32的位址,指向RCC register 所在的記憶體位址。

另外必須要說,我記得我碰過一個Macro 展開錯誤時的bug,那個錯誤真的非常非常難找,它就指向使用Macro 的那行,送一個錯誤訊息給你,可是你根本不知道是它展開到哪裡時出了錯。
上面這些,我的觀察啦,其實不太常用到,因為程式碼要長大到一定程度,選用Macro 才會有它的效益,一般狀況下用到的機會其實不大。
但Rust 的確提供這樣的寫法,在必要的時候,Macro 可以用極簡短的code 達到非常可怕的功能。

2015年4月26日 星期日

Linker script 簡介

Linker script,就是給Linker 看的script。

Linker:
當然這樣是在講廢話,首先要先知道Linker 是什麼:在程式編譯成物件檔之後,會把所有的物件檔集合起來交給連結器(linker),Linker 會把裡面的符號位址解析出來,定下真正的位址之後,連結成可執行檔。
例如我們在一個簡單的C 程式裡,include 一個標頭檔並使用裡面的函數,或者用extern 宣告一個外部的變數,在編譯成標頭檔的時候,編譯器並不清楚最終函數和變數的真正位址,只會留下一個符號參照。
待我們把這些東西送進linker,linker就會把所有的標頭檔整理起來,把程式碼的部分整理起來、變數的部分整理起來,然後知道位址了就把位址都定上去,如果有任何無法解析的符號,就會丟出undefined reference error。

我們可以試試:
外部函數,在一個foo.h 裡宣告,並在foo.c 裡面定義:
int foo();

外部變數,在var.c 裡面定義
int var;

在main.c 裡面引用它們:
#include “foo.h”
extern int var;
int main(){
  var = 10000;
  foo();
  return 0;
}

開始編譯
gcc -c main.c
gcc -c foo.c

這樣我們就得到兩個物件檔 main.o跟foo.o,我們可以用objdump -x 把物件檔main.o的內容倒出來看看,其中有趣的就是這個:
SYMBOL TABLE:
0000000000000000 g F .text 000000000000002a main
0000000000000000 *UND* 0000000000000000 var
0000000000000000 *UND* 0000000000000000 foo RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000011 R_X86_64_PC32 var-0x0000000000000008
000000000000001f R_X86_64_PC32 foo-0x0000000000000004

可以看到var, foo 這兩個符號還是未定(UND, undefined),若我們此時強行連結,就會得到:
main.c:(.text+0x11): undefined reference to 'var'
main.c:(.text+0x1f): undefined reference to'foo'

必須把foo.o 跟var.o 兩個檔案一起連結才行。

--
Linker script:
好了Linker講了這麼多,那linker script 呢?

Linker script 可以讓我們對linker 下達指示,把程式、變數放在我們想要的地方,一般的gcc 都有內建的linker script,平常我們開發x86系統跟arm系統,會使用不同的gcc,就是在這些預設的設定上有所不同,要是把這團亂七八糟的東西每key一次gcc 都要重輸入就太麻煩了;可以用ld --verbose 輸出,這裡看到的是支援x86 系統的linker script ,講下去又另一段故事,先跳過不提。

我們這裡拿燒錄在STM32 硬體上的linker script 來講,linker script 可見:
https://github.com/yodalee/mini-arm-os/blob/master/02-ContextSwitch-1/os.ld

Linker 的作用,就是把輸入物件檔的section整理成到輸出檔的section,最簡單的linker script 就是用SECTIONS指令去定義section 的分佈:
SECTIONS
{
. = 0x10000;
.text : { *(.text) }
. = 0x8000000;
.data : { *(.data) }
.bss : { *(.bss) }
}

在Linker script 裡面,最要緊的就是這個符號 '.' location counter,你可以想像這是一個探針,從最終執行檔的頭掃到尾,而 '.' 這個符號就指向現在掃到的位址,你可以讀取現在這個探針的位址,也可以移動探針。
不指定的話location counter 預設會從0的位置開始放置,而這段script,先把location counter 移到0x10000,在這裡寫入.text section,再來移到0x8000000放.data 跟.bss。
這裡檔名的match 支援適度的正規表示式,像*, ?, [a-z] 都可以使用,在這裡用wildcard直接對應到所有輸入檔案的sections。
光是SECTION 就講不清的用法,把指定某檔案的Section (file.o(.data)),排除某些檔案的section (EXCLUDE_FILE)
幸運的是,通常我們都不會想不開亂改linker script,這些位置的放法要看最終執行的硬體而定,亂放不會有什麼好下場。
另外linker script 也定義一些指令,這裡列一些比較常用的:

ENTRY:
另外我們可以用ENTRY指定程式進入點的符號,不設定的話linker會試圖用預設.text 的起始點,或者用位址0的地方;在x86 預設的linker script 倒是可以看到這個預設的程式進入點:
ENTRY(_start)

既然linker script 是用來解析所有符號的,那它裡面能不能有符號,當然可以,但有一點不同,一般在C 語言裡寫一個變數的話,它會在symbol table 裡面指明一個位址,指向一個記憶體空間,可以對該位址讀值或賦值;而在linker script 裡的符號,就只是將該符號加入symbol table內,指向一個位址,但位址裡沒有內容,定義這個符號就是要取位址。
一般在linker script 裡面定義符號,都是要對記憶體特定位址作操作:
以上面的STM32 硬體為例,因為FLASH 記憶體被map 到0x00000000,RAM的資料被指向0x20000000,為了把資料從FLASH 搬到RAM 裡,在linker script 的RAM 兩端,加上了:
_sidata = .;
//in FLASH _sdata = .;
_edata = .;

等於是把當前 location counter 這根探針指向的位址,放到_sdata 這個符號裡面,所以在主程式中,就能向這樣取用RAM 的位址:
extern uint32_t _sidata;
extern uint32_t _sdata;
extern uint32_t _edata;

uint32_t *idata_begin = &_sidata;
uint32_t *data_begin = &_sdata;
uint32_t *data_end = &_edata;
while (data_begin < data_end) *data_begin++ = *idata_begin++;

注意我們用reference 去取_sdata, _edata 的位址,這是正確用法。

Linker script 還定義了PROVIDE 指令,來避免linker script 的符號跟C中相衝突,上面如果在C程式裡有_sdata的變數,linker 會丟出雙重定義錯誤,但如果是
PROVIDE(_sdata = .)
就不會有這個問題。

KEEP 指令保留某個符號不要被最佳化掉,在script 裡面isr_vector是exception handler table,如果不指定的話它會被寫到其他區段,可是它必須放在0x0的地方,因此我們用KEEP 把它保留在0x0上。

MEMORY:
Linker 預設會取用全部的記憶體,我們可以用MEMORY指令指定記憶體大小,例子中我們指定了FLASH跟RAM的輸出位置與大小:
MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 40K

} 接著我們在上面的SECTION部分,就能用 > 符號把資料寫到指定的位置
也就是例子裡,把 .text section全塞進 FLASH位址的寫法,如果整體程式碼大於指定的記憶體,linker 也會回報錯誤。

結語:
Linker 其實是個古老而複雜的東西,Linker script 裡面甚至有OVERLAY這個指令,來處理overlay 的執行檔連結,但一般來說,除非是要寫嵌入式系統,需要對執行檔的擺放位置做特別處理,否則大部分的程式都不會去改linker script,都直接用預設的組態檔下去跑就好了。

這篇只介紹了極限基本的linker script,完整內容還是請看文件。

參考內容:
Linker script document:
https://sourceware.org/binutils/docs/ld/Scripts.html

如果要知道linker如何處理位置無關符號,請見:
https://www.technovelty.org/c/position-independent-code-and-x86-64-libraries.html

2015年4月13日 星期一

用llvm 編譯嵌入式程式

最近幾天在研究嵌入式系統,玩一玩也有一些心得。
課程上所用的編譯工具是arm-none-linux-gnu toolchain,在Archlinux 下可以用如下的方式安裝:
$ yaourt -S gcc-linaro-arm-linux-gnueabihf
$ yaourt -S qemu-linaro
$ yaourt -S arm-none-eabi-gcc49-linaro
$ yaourt -S arm-none-eabi-gdb-linaro
$ ln -s /opt/gcc-linaro-arm-linux-gnueabihf/libc /usr/arm-linux-gnueabihf

不過最近心血來潮,想來試試如果用另一套編譯器 LLVM 來編譯看看,至於為什麼…好玩嘛(炸),總之這裡是設定筆記:

主要參考網址:
http://clang.llvm.org/docs/CrossCompilation.html
https://github.com/dwelch67/mbed_samples/

用上LLVM 的優勢是,它在編譯時會將程式碼轉換成與平台無關的中間表示碼(Intermediate Reprsentation, IR),再透過轉換器轉成平台相關的組合語言或是底層的機械器。不像gcc 針對不同的Host/Target的組合就是不同的執行檔和標頭檔,在編譯到不同平台時,都要先取得針對該平台的gcc 版本。
註:上面這段是譯自上面的參考網址,雖然我有點懷疑這段話,不然gcc 命令列參數那些平台相關的選項是放好看的嗎?

我嘗試的對象是mini-arm-os 00-helloworld,目標device 是STM32
https://github.com/embedded2015/mini-arm-os

前端的 c 我們先用clang 編譯為llvm IR code,用llvm 的llc 編譯為 object file,因為目前LLVM 的linker lld還在開發中,只能link x86上的elf 檔,要連結ARM 我們在link 階段還是只能用biutils 的ld,以及biutils 的objcopy,這樣看起來有點詭異,有點像換褲子結果褲子只脫一半就穿新褲子的感覺。

最後的Makefile 大概長這樣:

CC := clang
ASM := llc
LINKER := arm-none-eabi-ld
OBJCOPY := arm-none-eabi-objcopy

CCFLAGS = -Wall -target armv7m-arm-none-eabi
LLCFLAGS = -filetype=obj
LINKERSCRIPT = hello.ld

TARGET = hello.bin
all: $(TARGET)

$(TARGET): hello.c startup.c
$(CC) $(CCFLAGS) -c hello.c -o hello.bc
$(CC) $(CCFLAGS) -c startup.c -o startup.bc
$(ASM) $(LLCFLAGS) hello.bc -o hello.o
$(ASM) $(LLCFLAGS) startup.bc -o startup.o

$(LINKER) -T hello.ld startup.o hello.o -o hello.elf
$(OBJCOPY) -Obinary hello.elf hello.bin

其實重點只有在target 指定的地方,其他的就沒啥,只是這樣一看好像沒有比較方便,而且這樣根本就不是用 llvm 編譯,最重要的Link 階段還不是被 gcc 做去了= =
在lld 完成前也許還是乖乖用 gcc 吧?

對LLVM 相關介紹可以見:
http://elinux.org/images/d/d2/Elc2011_lopes.pdf
各種biutils 的替代品列表:
http://marshall.calepin.co/binutils-replacements-for-llvm.html
LLVM lld開發中,是不是該進去貢獻一下Orz:
http://lld.llvm.org/