From 82ca9ec4cb7368ae28d3036cbe843adb0e47b67d Mon Sep 17 00:00:00 2001 From: asterich Date: Tue, 19 Sep 2023 22:47:44 +0800 Subject: [PATCH 1/2] add article: elf2flt-flt-analysis --- articles/20230919-elf2flt-flt-analysis-0.md | 172 ++++++++++++++++++ .../bflt-structure.png | Bin 0 -> 10761 bytes 2 files changed, 172 insertions(+) create mode 100644 articles/20230919-elf2flt-flt-analysis-0.md create mode 100644 articles/images/20230919-elf2flt-flt-analysis-0/bflt-structure.png diff --git a/articles/20230919-elf2flt-flt-analysis-0.md b/articles/20230919-elf2flt-flt-analysis-0.md new file mode 100644 index 0000000..6a30f46 --- /dev/null +++ b/articles/20230919-elf2flt-flt-analysis-0.md @@ -0,0 +1,172 @@ +> Author: Odysseus <320873791@qq.com>
+> Date: 2023/09/19
+> Revisor: walimis <>
+> Project: [RISC-V Linux 内核剖析](https://gitee.com/tinylab/riscv-linux)
+> Proposal: [为 ELF2FLT 完善独立编译与安装支持](https://gitee.com/tinylab/riscv-linux/issues/I79PO2)
+> Sponsor: PLCT Lab, ISCAS +# ELF 和 FLAT 的区别 + +## 介绍 + +bFLT 是一种用于嵌入式系统的可执行文件格式，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 + +而 FLAT 的二进制文件通常成为 BFLT，是基于原始的 ELF 文件格式的一种简化版本，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 + +ELF 的头较为重量级，bflt 格式对文件头和一些段信息进行了简化。ELF 支持动态加载，因此更统一使用和创建动态链接库。而 FLAT 并不支持动态加载。 + +接下来我们主要从头文件和重定位的方式解析两种格式的区别。 + +### bflt 程序结构 + +bflt 格式的结构如下： + +![uclinux_file_bflt](images/20230919-elf2flt-flt-analysis-0/bflt-structure.png) + +其中，header 由以下结构体定义： + +```c +struct flat_hdr { + char magic[4]; + uint32_t rev; /* version */ + uint32_t entry; /* Offset of first executable instruction with text segment from beginning of file */ + uint32_t data_start; /* Offset of data segment from beginning of file */ + uint32_t data_end; /* Offset of end of data segment from beginning of file */ + uint32_t bss_end; /* Offset of end of bss segment from beginning of file */ + + /* (It is assumed that data_end through bss_end forms the bss segment.) */ + + uint32_t stack_size; /* Size of stack, in bytes */ + uint32_t reloc_start; /* Offset of relocation records from beginning of file */ + uint32_t reloc_count; /* Number of relocation records */ + uint32_t flags; + uint32_t build_date; /* When the program/library was built */ + uint32_t filler[5]; /* Reserved, set to zero */ +}; +``` + +如上，bflt 的 header 只有 19 个字节。 +header 以由"bFLT"四个字符组成的幻数开头。下一个字段 rev 表明 bflt header 的版本。目前而言，bflt 有两个主要的大版本（version 2 和 version 4），不同的 bflt 版本支持的 flags 和重定位格式都有所不同。 + +接下来的字段标记程序各段的起始/结束位置：entry 为程序执行的第一条指令，也就是.text 段的起始位置；data_start 和 data_end 标示.data 段的起始/结束位置；bss_end 标示.bss 段的结束位置，bflt header 并未标示 bss_start，而是假定从 data_end 到 bss_end 都为.bss 段；stack_size 指定栈空间大小；reloc_start 和 reloc_count 共同决定重定位表的范围，其中 reloc_start 标示起始位置，reloc_count 表明重定位条目数。 + +flags 字段可能的取值如下： + +```c +#define FLAT_FLAG_RAM 0x0001 /* load program entirely into RAM */ +#define FLAT_FLAG_GOTPIC 0x0002 /* program is PIC with GOT */ +#define FLAT_FLAG_GZIP 0x0004 /* all but the header is compressed */ +#define FLAT_FLAG_GZDATA 0x0008 /* only data/relocs are compressed (for XIP) */ +#define FLAT_FLAG_KTRACE 0x0010 /* output useful kernel trace for debugging */ +#define FLAT_FLAG_L1STK 0x0020 /* use a 4k stack in L1 scratch memory. */ +``` + +其中前三个 flag 是 version 4 新增的。FLAT_FLAG_RAM 表明程序不是 XIP 的，执行时会完全加载进内存；FLAT_FLAG_GOTPIC 表明程序是有 GOT 表的 PIC 程序，此时程序.data 段的开头有一张 GOT 表，该表以 -1 结尾，包含需要在运行时重定位的偏移量，用以实现动态链接。 + +重定位表由重定位条目组成。在 version 2 中，重定位条目定义如下： + +```c +#define OLD_FLAT_VERSION 0x00000002L +#define OLD_FLAT_RELOC_TYPE_TEXT 0 +#define OLD_FLAT_RELOC_TYPE_DATA 1 +#define OLD_FLAT_RELOC_TYPE_BSS 2 + +typedef union { + uint32_t value; + struct { +# if defined(mc68000) && !defined(CONFIG_COLDFIRE) + int32_t offset : 30; + uint32_t type : 2; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# elif defined(__BIG_ENDIAN_BITFIELD) + uint32_t type : 2; + int32_t offset : 30; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# elif defined(__LITTLE_ENDIAN_BITFIELD) + int32_t offset : 30; + uint32_t type : 2; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# else +# error "Unknown bitfield order for flat files." +# endif + } reloc; +} flat_v2_reloc_t; +``` + +在 version 4 中，重定位类型被去掉，一个条目就是一个偏移量（以 0 为基）。各偏移量在重定位时依靠与程序各段起始/结束位置（例如 entry、data_start、data_end、bss_end）进行比较来确定其所处的程序段。 + +### ELF 文件格式 + +ELF 文件结构如下图所示：（这边改成文件夹下的 elf.png） + +ELF 文件格式的 header 有 32bit 和 64bit 两个版本，这边给出 32bit 的版本： + +```c +#define EI_NIDENT 16 + +typedef struct elf32_hdr{ + unsigned char e_ident[EI_NIDENT]; + Elf32_Half e_type; + Elf32_Half e_machine; + Elf32_Word e_version; + Elf32_Addr e_entry; /* Entry point */ + Elf32_Off e_phoff; + Elf32_Off e_shoff; + Elf32_Word e_flags; + Elf32_Half e_ehsize; + Elf32_Half e_phentsize; + Elf32_Half e_phnum; + Elf32_Half e_shentsize; + Elf32_Half e_shnum; + Elf32_Half e_shstrndx; +} Elf32_Ehdr; +``` + +64bit 版本的 header 与 32bit 版本的 header 基本相同，区别仅仅是字长的区别 + +header 中的 e_ident 字段用于标识文件类型，是一个 16 字节的表示，其中前四个字节为魔数，取值是固定的`0x7f`、`'E'`、`'L'`、`'F'`，[4,4]字节为文件类型，[5,5]字节为字长，[6,6]字节为字节序，[7,7]字节为版本号，[8,15]字节为保留字节。 + +e_type 字段标识文件类型，e_machine 字段标识目标文件体系结构，e_version 是当前文件的版本，e_entry 是程序入口地址，e_phoff 是程序头表的偏移量，e_shoff 是节头表的偏移量，e_flags 是特定于目标文件的标志，e_ehsize 是 elf header 的大小，e_phentsize 是程序头表中每个条目的大小，e_phnum 是程序头表中条目的数量，e_shentsize 是节头表中每个条目的大小，e_shnum 是节头表中条目的数量，e_shstrndx 是节头表中节名称字符串表的索引。 + +e_type 字段决定了 ELF 文件的类型如下三种： + +* 可重定位文件（relocatable file）：包含可重定位的目标文件，可以用于链接生成可执行文件或者共享目标文件。 +* 可执行文件（executable file）：包含可执行的目标文件，可以直接被加载到内存中执行。 +* 共享目标文件（shared object file）：包含共享目标文件，可以被动态加载到内存中。 + +ELF 的节头表是节头数组。每一个节头描述其信息。sh_name 字段为节名，sh_type 字段为节类型，sh_flags 字段为节标志，sh_addr 字段为节的虚拟地址，sh_offset 字段为节的偏移量，sh_size 字段为节的大小，sh_link 字段为节头表索引，sh_info 字段为节头表索引，sh_addralign 字段为节的对齐要求，sh_entsize 字段为节头表中每个条目的大小。 + +除此之外，节中比较特殊的是如符号表，重定位表等。 + +### 重定位 + +bFLT 文件一般而言是 PIC 的，执行之前需要由加载器进行重定位。重定位有两种，一种是对全局/静态指针的重定位，一种是对 GOT 表的重定位。这两种重定位在没有 XIP 时使用相同的方法，即将程序基址直接加上偏移量。如果需要处理代码段和数据段不连续的情况以实现 XIP，可以通过如下方法确定偏移量所属程序段： + +```c +if (offset < (data_start - entry)) { + //pointing to code section +} else if (offset < (data_end - entry)) { + //pointing to data section +} else if (offset < (bss_end - entry)) { + //pointing to bss section +} +``` + +BFLT 文件通常是没有显式的重定位表的，而 ELF 文件的重定位信息被包含在其重定位表重，在加载 ELF 文件时，操作系统通过解析重定位表的信息，根据需要修正符号引用，以适应实际内存布局。这里的重定位也是支持不同类型的，绝对地址和相对地址都可以被使用。 + +总的来说，其在重定位的不同是他们的复杂性和灵活性的不同的决定因素。ELF 文件用更规范也更复杂的重定位方式，而 bFLT 文件则使用更简单，更紧凑的重定位方式。 + +### 共享库 + +bFLT 对共享库的链接在编译时而非运行时被决定，这点不同于带有 MMU 的系统。但是，程序在加载时仍然需要对共享库链接进行重定位。 + +共享库的重定位条目由两个部分组成：共享库的编号和所引用符号在共享库中的偏移。其中，共享库编号范围是 0~255，占用最高字节。例如，一个共享库的重定位条目为`0x030003a0`，表明该重定位条目指向编号为`0x03`的共享库当中偏移量相对于共享库为`0x03a0`的符号。如果该共享库被加载进`0x2000`，而使用该库的程序被加载进`0x1000`，那么该符号重定位后的绝对地址应当是 0x23a0。 + +而 ELF 文件支持动态链接，在运行时可以加载共享库而不需要将他们完全静态链接到可执行文件中，这样可以减少可执行文件的大小。ELF 文件的动态链接是通过动态链接器（dynamic linker）来实现的，动态链接器是一个独立的可执行文件，它在程序加载时被调用，负责加载共享库并进行重定位。 + +### 总结 + +总结来说，通过上文对 ELF 和 bFLT 的文件从头，结构，重定位和共享库的解析，其实可以看出其区别主要在于： + +1. 通用性：ELF 文件格式是通用的，而 bFLT 文件格式是针对嵌入式系统。 +2. 功能复杂性：ELF 文件格式支持动态链接，共享库，多种重定位类型，而 bFLT 文件格式更简单紧凑。 +3. 资源效率：BFLT 文件紧凑简单，对资源的利用率高，更适合资源有限的嵌入式系统。ELF 文件元数据更多，对资源的利用率低，更适合资源充足的系统。 diff --git a/articles/images/20230919-elf2flt-flt-analysis-0/bflt-structure.png b/articles/images/20230919-elf2flt-flt-analysis-0/bflt-structure.png new file mode 100644 index 0000000000000000000000000000000000000000..d059d56b0a4f1bd8262602d39d042164c30de693 GIT binary patch literal 10761 zcmc(FbyQSsxG#bNk^|Dh0E3itiAXcFq^Oj1N|#a&NFyi+(%tdV-6bI1DUwn{cSzoM z{LWeH+;!Le@7{C%02h0^XZGIj^Ze?0KdGt6;p0%@prN7RE67W~KtsDD1Ad-kV}c`+ zUMU>lpF7SkoqAJENfyw4;9RblK;bqM@;- zC`e1bbkpCNyPq`h>K1E%kGr}sf+Qk1!$T_3l(lky9G*_B&ic7hN0H$Z7HhVR0`brC zN7-F5jGm@n_$f>m&hUPm-g-AX4<_?XCG*s}Ug#aUx9G1&FF5Tf)gg9&daX-$bap0_ z!eB2b`^7&6BX4;~J_S?b$-rP(@QC2&~ zIrsm^A?jx?@;a54^qryPvFY%ji{8(ae5S)`l53o>Lm0Ru>8YdC+F&x9`{7DN5Y(ev zv)X=v(|W2{z?CS1{6F4a{UeK^lxU4ym1GTv`KA;di@~Ibv0T-}Oy?!4UB~1-f!N2x zLs@;~@CeSHe_jEqCR_L5aL!j@kxBerzbYkiw$AF zY5(!QItWVX+B-N~@J_7wb6`#;i?Tg_+ zWb0H}jpnH{I8UwK8~duprZjN(#P(OU!q#NbNsGcaCgqjuvxO z)yzlI2)~cheDrR6n&(=(dU5*QF;bo8y5@E+S1H~}rS;~pkE?m>T)6G1g)E_;LH6^o z_0CMy^U-6uTUhh<#mQFg)Ir>Av0g)^?EUk(t*H{OfkeUBcs`3wAsjAngH~fXUv5`?&tymeq5#DFgRaQupn$E>o}~YXlMf@qE^nlldB5N$C#X)$r2M@8QVzL^2{6 z<-(}fdRN!;b5lkQ3ttt)2z?Xb=Q&^(v>MAB(GI{RpXBaM5p7WUAXj_W_vZPpmvVJ` z&6oYrcP~$O#>_e9Y40rstX1ODo0l{oqVmdqQw$|8@AcoFNi47=bS`*Z7B!!OI*1Xl zo|J#{CaDho2nLf1Az{rpddYglO~T3obzdQ($(9-5U_>?~avS*u;-X`(O3i&Z8n~#i zVb#d_To)OIxb@s?(zH&UEYz+rUHTr-yhVN_JUx}ZS83E9=(JNcmB2=_OA!*41Cft= z?>FH+|KUhE|7Ct;T_iTbH}6aK`;Hk}U!1+rvzlz#FH~#)bjKQaG0uDmZca=$f-TLrqf8?wAe&~5Q*I&HtVN$7tMmkjx)OCs|}{z#!V zAEIz{$MtHzop4~{F0!I>Du!L#crZj-R@Q0^it)5I@CJ?-r;RkA<}?3HFg`t%$*x=7 zKP$Nuw#Dj^G&QBsAucjvR!jp|=^d=}D|$HS@{1g1tSR7cDl<2TzMadO5C?J{w%gR&K)dFAeF zIB|=1ONr;`K0Nj&Jhs+WJwTbU_|#$XBkH+%Kb$)ZYPfKN)9FvW zZ$8u=4GN>qw^GGv9T8c}@sd2?ArTEztyIg~{}j_Yo%?@&H0s+HkriD=$CL#k3r>9; zYk2AohT_)j9l}m4@?m1a6d}+cwGRF7(-a{raixk+*H{Q1KKY!EG-UChUT1xg=a6D- zxUGSg!DlgONuRObsfL#^B!2tm*}F~CuwWKy9uhyxqqTwZ_d7by($Y(SCDuDWJ>WI@ zffo-djoqMmHc9#8ml4N#GMl3Nmb@m3s&Bd`696<%M2I%dH_=YLnO=yaS6t!1laT}H zX!EmNX5Mp8^zBGS03HRm1OZe8xy1}HKZD_`LiF8O6Lu9EWKdaweisLcKQcIWepwW2iz=b3A z;5v+lhsWb4-XbN!A{Fs^j{#r87xFN&S4gVyKd-7H~+>Pi^fA^Jrp5#cpN6 zxvZ`{ZCPpQ?vp74E=_&+?3L~acnCQcCjhX?EfhO=s;d>uHn^5hi+jBRoXY&?aCJ;d zdcI8!uT`ap^>ty~c(I-?s9f`6$jE9~I9BC#hx}oAe4Pc)0)_R|`s-BTsjJZ7F$^;6-gOv@FazdQk)v zYnG(g%+*gMDU6qy$n_)&mK^WS>3UskFz-}6g4r*bczJO%VzmWQ(WZq%j6OAYoNP^5 z(;9iDy!&@A3qd9n;t`zY9zf)ewLe^JUiZ;cz*eqXW#ge zM&oI0HkxPJaIl!MKJvHcd|33;)}2=OY=PuY`-=aLY+6 z@Q|>wqclN+pgrf&`Vcs)Ka?VBw!hf67RADx|2yWSSm+PQRR$6^9ctN-RtbbRK@~g}w2#;3m&FSu3!IYrw3~CJ`+JgwK=>`)8Rrf0P zFlvWx;=7H(heUH3=-0b!z)(^tR^LNm6Hq6R95I>(h*yfyj~M}RM?0Z!d5ugZJQRoV%ouWHRRefsKOA;?&9kVi&YJkC`TWv$-!Gbgpas2JypDe7IqngSo z6G|3MC152V&ueB1-acS;h>*u|Uh_~0DVs~{+IYT(hmt7|Nzb?6%gbhmD?P*y9~N|J zmzzfXvTIN_Ha2!St~G4)9j$Y=_*rEg`xz>#gL^@6wzp8?6BJ>^pG=g3G-(92Y&M#u zKvfMo=9@`ZSPy`^LJThH;^5larvxqTT4OoNj2bygGa^d%5Fk#?$9>g}l~UWp9jPfP z^UoHkWg|GQYRWTv&nwL2QXC1Y;Ij{ih$4!ybY7R}7hRWOU=c(m2v{dnbR@vs$GytGPKIt|hpntiVjwA7?_~lUsV~`j=vJ449RWl%gc!38-3UCNojb(focGrkC+~VCi{I2$);)9lE$v(*AN}}MrTFTH zQ&7JxSUH`wKf-9(fP#t&#DCa(G$dZKzJGHrG`Sou&IxqIH^k-XhUe9-x3y^a?nnEU z>(|~3>nWZpP`AZ9qO{nTB<)?t8)K{B`y#r#<=qcD$+H3Vttn;zBi09=%rK02QS5^X zpLu^?SKMPh(0SJtEkFgJda++U1E|=|b;{H>fGhD8tR|_(hAD-tcE75Xb5xT5@qX)l z^CvejSe!rG5q}j}oLE}#D|J7Jkvnpjp5x&YoBb0w^r=IutGJkhog1SCa1#n%gf&;d zOO(6r%|E&hX>i?}v_{?n&T1*tsZtzb&~g-UUQ=oc^GdC-7}`YA&ij3*mD-px@IFC^ zLB5`|*L&Swy8`SC+k@)vyT^;TmwUORH-Frz0?JyYWo3uwF)oP?xJ6@ z(C>|5&L;fM*U06MOLJZyq*BS03!hvDOw{}70dwV~<u?tXozMpy(J@~f@g#{Kv&|*R!H!OmjsORC$q}WXUDBSH{|hUT!)}Jr zB3(gzrpCeB_HDwpfJ=b!1yxG*R{+3Yi!+~R*v{6LrL@N~i?N+ktDWEPQ%mAC3pw3r zx;pIB8McolJ{HZWHs9lVkriAQSq|E7%X9e`v;Va|ZmO-$P^{d}nx`mWaq`SCMkwD;|SlAM{2x+9S zR14!Syl6?v>jwbf57%KX?h*z(2}3M^n5SAyaJW+NI>AjmZ+O3BI$dfsT4k+y?T~KI z0}u2!5L8VOA*Q7*nNowu-oqgow*F{ugEyFV-|r>`$RizQmtU6$J1GeX)KWvunD=Pi zj_EVP_Y$m&M-F6-+G7P!*`z#QGO1H%8hK@yjl-{eF(jObT2dyd4sru)XZ)S)QOXoYh-s_Z7 zgBs`pDMgo<1%G0nvosMP1!){npA-5UmPvutOJ( ztEKJet#ja|)l@M;g${k!8<`%|Pn3PHIC9yskoARCX%2`N0npzn`?8 z0#7D`J4o(6Pb^Vrq@mX%sAP6%m)fIxJUVRMO3U=2#j$Lo|J{E5*Khv6n6!ZGcUzM^ znc-sp2rp&-06HTZG;{qCR9%rGge0akfa8?0O}{U{%=63+1@^n-DpACNuz+Y3yk{wV zGo5dAZx(IiU@xyXY(sAfJoq}3y5FFkD{7U3O4P1Q0L1s1hbWAs`pKu=|IB78|AM&CbD`qq*HSr zJ&y(ivq45wUpR>z$$U5F&Z3^-Z+AcBk|;yE6-c^|%@TOUDF1>|kD$QDqI2{t#Y|Xl zysj^LKzcQxJ%YbZ6bxWD1}JAmz*War^G%*+AVl*JPaFiwY@_^R&OtB{gK1Y74Pef) zBZ52-ILKZSg+oREIZG9BAAOU49F{Jh;x8tBj0F{Pk`8BJV90h@`c7qx#GM7KK8aTZ zkmXZI$Y_ouP?y;NOxF})cNYLmAB%Eh`|13CXy2F)5-k9$oQiuWeTfan`=}JhEg3#? z7b;*C74}TC;I%T4U^xOJIRPM{Gi5e&MHj$@#{hs6sX)t&hGU_ zGKRj)e<9{dAOgX{&$DL{(3B4psEf*;uoJ8wezb+bsll1r(JCmFSN|jY>>Dp`H4Rpe2#q9=} zo`Gaz?^$mIgWSqq%WX`NZcQ(!eKVlt%e`;CoNKxPseL%Jo2gV#NqTBjoJ70ZX}v!K za@K^3`{>uun_2HzAj#t^fTuMg3IW+&EO>R++Le|OLW#&wuI7C`xjzfHH_RaJsSvr` zu9)%Povo`l-uX2(%W(+!^Kut)z7)jB#Ps8hPzy+C6@fxKsRE*#$Kt{9*3{5hGfUpY z#Y5rug?kr(K?by8hd4t)uERO^sN_~o1k5toeFhMt1GCS z6R?3I0HKw#F6fx`{&!q1HJzn2L#swWAQoS6zp7O# z0OyaFrvE&sfPq&LLt>Xo)iytWH|RIIIXVXfH-0}#4^E&@NCyZs;WQvH7031oqGAc# zn`_Wa>~jDww~rxQ1O{;Wo9AwwTyGR>=K9ibI^3hh`{?WgDo_9dCpuZ!b#sfHOP?JG z8v)G+bR;`_Aq!nQw^v|os(Nfn3=k(1YdA#iGSm2#wSy_51q0fj7YS&dy_5}y7Wu?d zkJEvMa{Y62xp(4qcQ!!Enc7d#P4t3E`xirfqyIaW6d`9>ea{^MP#@t+iBFWQ0#>!(m8ZG70+Lnx^3j1u z)a}h#%i882u&gQ|tlheFMKxNTl(c>X&$DOsnSUyn(-$~+d0(^>UcUoWlKZkyOWm$^ z3DY@99weS8R92q=T*m@z>jA{cMnpsuDdcR93Sdxai(TV^?2d`_H}bP(ioJkK=ha@b zc@B4w-^5(~IqKV;Ysd!9@&f8s^2@$OuOw3_d|@j_*KWkbpW7-%aL(l$l$=FPf)}Xg zF^~P3hTZz--cK&XzwsG;zl*@Ps+Df@_d2j|{v+Fx_B@KkXz<0qvzT=ke1=&HN)-ZM z0-v}^l!F3lTahcG}J2eLffM{c<;Aeh?&@l9Bs{hJ2fb#y%x zQs-Vw4;FG>LpJIL8pDSCVX{_bY3Q;+CAGhCoKI5&HiUt)n|RAl$@|9bj179}H~!g% zIcUHFhxAD*#!0oD7nVBHbC)%M%hrN}zx!B75edjBeJZPB zu=Is z&;BGK4eNN|NWX%~ffe7ml;h$13*Vs$5Js+o{C)CPuvDV_n%($QqwsDm{N|*@JHFw; zQlBe`cP@lF*Es~9x(k~9eqe2D-V-Tv#!#Nhs0;nDFX_x2px6y3@~*?aD-!fstln|? zhXN=j)KskH-Z$MyTEu6qJ&3Z(U9tq?r?SC!tRnMhev1?@Q?A`yUs|^bvU_2Y`Be>x zGhLnIFFsLl_)pH_#@EVVm=5X5=_e+o=Iix3~;ke^AN_UEzXlL#x5 z;sV5Ej=Sg<_Y<(7ZW4(|Hv@?xA_1Lo#r1*2T%S(}J%6#)%Wnk1unT4RVZ$sk5NSH>oh$5!o>6d`bUH?sYL9N_xkGf#Cv_o>i+2A{R2eVGd*LBzS?%Z8};RVeSh z$X48V7JTC=pSc#I?$|0Y>*sl=q|MXGvx2NoT~e;bvmv~A1absl3yV}3BlXd7p52rdgv2PVc? zp5)pOIfeUD?RllZa~M}^J311I^K$SEg0A=MU%Qhd?&gbod0RU?;Mb`z9ArmJ=1>Ow zPm+k-3Qrs~uW4+jy)elU=XVLz&6W-ti4KSh!`uE*xxtkzRpr?Mn+HTN32EMd0abnd zxbR+MW;U1_Ty(Pmff>+1`7!OM&5nx>6Qh*lqx=3e(#RWK;0X>q(fA3)?1^o3_ zlf?GI+cY@c9)&Xurvoc?NLPp*PPL57)tL4RG7IL8&!(lo@vN_HRPhG~2MWCbyXjxf zN-q!niM_ba*3W5k8MjsacLca=eGwl^6GX@!|Io>*McrrC*FUJKOV2u4QUe4P!2upl z%p7hztp>{SiCl*8MmphM>c<_f&GG!q>)`1~wD2>d=tu0_p@>da@cu}6r(Y3O6@lRI z0_Qc;?eUoENou~&Su2xDdNt7bj~*r&?MU%!-`<}-qI|e$;>W)o8YVze#&Xw7yiiK@ z?+tu6H!Eqr_@~4Wa_8IEk*I1AZ!!a2I_0aJIEeL2Z2Gcn&QE;1BiLF?ci4{aj#fCt zb8ULccutD{TNxo_4b#~992JJ8QcFUX@`=gOXPU|AH@|yMTR&h@k}qctpWB+%?@HCU zc+nabskH!Ukeiu85mBlqCx|ucLZt%I<>>~)g_~ida|e6j37iSPPpfLlZ|8g3^rhqS zzU;W{SP$MIEh)6x_|%o!3s#yO$q9T+a`LPb3+B|q)} z?Ot-P+jD)?*L6%=Psoe!S@*{t>3P2HIsFP zyOHAKPU>3~;^aR5<}J8;KGuI@FGclb4qzYxSHTeTWIe-NH%mU^QNs&N-vs^};h(8N z??`s+zMlVXJsLSDPFpl#c_B|v2f<;<`$GS8SX#DJ8yn645f0O1tfPED4ZuXUu@Qte z&AweTk$y~%Vph9av2if%_Msos;2d}i^R?Ah6OZ+5F>j@9Nt73JQ#=&CF>~t9;k0zJ zZW#B-PGMa)bEoTTz0q4qK5-IinbHGiU>-V>8oJ=!{guAiOXUz62)oV%v!)WGjZ@(a zT5cf305NHBQb zzIZ=j>2w|T5+pW8#Y}{VkW&GcX-O^tM9A^b5?L;kd{8$D#0xJHd)(d(e3#vu4thBD z9LB(KLVZEXliew0d$`-MHz{u7fPt_u>x-E%X|?3E^8UE)#}hjguqeq#D$t8V`WPwJ zi}Y)s6({$---7j>L_m5RZKR`9=q`&@nA_U4(*nl&-1=8?cCECk*Lb68Jz=?Okoi2l z`aVQDQ>f6_Sab{xEp~Ja?(_Io4ipsQ!k;;+DK`_G^_Hfj70#i?szHtlGwk?y1{On z4GnfT{YDV@%!JGTi_A*0U9I>`UM9vuIX8xB_c1grRWvNY&L=RYYU!oxVK8fL`@{1GOC)&GK{P_&nm*5V8 zzUtr`je`gKPWab8R{49ZAN1(ES2Ts^ex#0S+vv4!uwbcB6eYz~e%W~H_Woh`ak}9b z1$NOjF#?73|J=1Eg87RGHT~5j=$g!7p+MMyjXIpKCI7vpLSp}9!m`6BWUDf59%134 zr*Xxt%70H`v%3ankE)gCEW-&!v#vu}v;>{NOr^PqoW%w8#(WSqrBRxSW&qRI>~Khn zbCHf<$HjH4apii!{dteAqC3ov&Z3=*M#>T04Er`mV2@hfyJ1T_u<})c7lO|-jqgGC7{H=8}URi zL;HXs+46{KhdWWLqy{!ixa`cl0$U;?Nwz0`bAebJXdTkzMFZgL5U&$B z|MEL1@<$+*8OJY#!C;Y5E2z;b7@%f_Dhy|X!9KL>KL_%KtYAlqmd5eZagz1^c!rt< zuLdDF3H3BKu7(?T{Xl{-4D4w6Ldho!ayIj@U|+7fKj9msf2Z(b|0BB1^! V;YFG~VEZPTf{coEv6P|j{{j!7 Date: Tue, 19 Sep 2023 22:52:18 +0800 Subject: [PATCH 2/2] fix article: elf2flt-flt-analysis-0.md: commit correct result of tinycorrect Signed-off-by: asterich --- articles/20230919-elf2flt-flt-analysis-0.md | 356 ++++++++++---------- 1 file changed, 184 insertions(+), 172 deletions(-) diff --git a/articles/20230919-elf2flt-flt-analysis-0.md b/articles/20230919-elf2flt-flt-analysis-0.md index 6a30f46..7a7f594 100644 --- a/articles/20230919-elf2flt-flt-analysis-0.md +++ b/articles/20230919-elf2flt-flt-analysis-0.md @@ -1,172 +1,184 @@ -> Author: Odysseus <320873791@qq.com>
-> Date: 2023/09/19
-> Revisor: walimis <>
-> Project: [RISC-V Linux 内核剖析](https://gitee.com/tinylab/riscv-linux)
-> Proposal: [为 ELF2FLT 完善独立编译与安装支持](https://gitee.com/tinylab/riscv-linux/issues/I79PO2)
-> Sponsor: PLCT Lab, ISCAS -# ELF 和 FLAT 的区别 - -## 介绍 - -bFLT 是一种用于嵌入式系统的可执行文件格式，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 - -而 FLAT 的二进制文件通常成为 BFLT，是基于原始的 ELF 文件格式的一种简化版本，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 - -ELF 的头较为重量级，bflt 格式对文件头和一些段信息进行了简化。ELF 支持动态加载，因此更统一使用和创建动态链接库。而 FLAT 并不支持动态加载。 - -接下来我们主要从头文件和重定位的方式解析两种格式的区别。 - -### bflt 程序结构 - -bflt 格式的结构如下： - -![uclinux_file_bflt](images/20230919-elf2flt-flt-analysis-0/bflt-structure.png) - -其中，header 由以下结构体定义： - -```c -struct flat_hdr { - char magic[4]; - uint32_t rev; /* version */ - uint32_t entry; /* Offset of first executable instruction with text segment from beginning of file */ - uint32_t data_start; /* Offset of data segment from beginning of file */ - uint32_t data_end; /* Offset of end of data segment from beginning of file */ - uint32_t bss_end; /* Offset of end of bss segment from beginning of file */ - - /* (It is assumed that data_end through bss_end forms the bss segment.) */ - - uint32_t stack_size; /* Size of stack, in bytes */ - uint32_t reloc_start; /* Offset of relocation records from beginning of file */ - uint32_t reloc_count; /* Number of relocation records */ - uint32_t flags; - uint32_t build_date; /* When the program/library was built */ - uint32_t filler[5]; /* Reserved, set to zero */ -}; -``` - -如上，bflt 的 header 只有 19 个字节。 -header 以由"bFLT"四个字符组成的幻数开头。下一个字段 rev 表明 bflt header 的版本。目前而言，bflt 有两个主要的大版本（version 2 和 version 4），不同的 bflt 版本支持的 flags 和重定位格式都有所不同。 - -接下来的字段标记程序各段的起始/结束位置：entry 为程序执行的第一条指令，也就是.text 段的起始位置；data_start 和 data_end 标示.data 段的起始/结束位置；bss_end 标示.bss 段的结束位置，bflt header 并未标示 bss_start，而是假定从 data_end 到 bss_end 都为.bss 段；stack_size 指定栈空间大小；reloc_start 和 reloc_count 共同决定重定位表的范围，其中 reloc_start 标示起始位置，reloc_count 表明重定位条目数。 - -flags 字段可能的取值如下： - -```c -#define FLAT_FLAG_RAM 0x0001 /* load program entirely into RAM */ -#define FLAT_FLAG_GOTPIC 0x0002 /* program is PIC with GOT */ -#define FLAT_FLAG_GZIP 0x0004 /* all but the header is compressed */ -#define FLAT_FLAG_GZDATA 0x0008 /* only data/relocs are compressed (for XIP) */ -#define FLAT_FLAG_KTRACE 0x0010 /* output useful kernel trace for debugging */ -#define FLAT_FLAG_L1STK 0x0020 /* use a 4k stack in L1 scratch memory. */ -``` - -其中前三个 flag 是 version 4 新增的。FLAT_FLAG_RAM 表明程序不是 XIP 的，执行时会完全加载进内存；FLAT_FLAG_GOTPIC 表明程序是有 GOT 表的 PIC 程序，此时程序.data 段的开头有一张 GOT 表，该表以 -1 结尾，包含需要在运行时重定位的偏移量，用以实现动态链接。 - -重定位表由重定位条目组成。在 version 2 中，重定位条目定义如下： - -```c -#define OLD_FLAT_VERSION 0x00000002L -#define OLD_FLAT_RELOC_TYPE_TEXT 0 -#define OLD_FLAT_RELOC_TYPE_DATA 1 -#define OLD_FLAT_RELOC_TYPE_BSS 2 - -typedef union { - uint32_t value; - struct { -# if defined(mc68000) && !defined(CONFIG_COLDFIRE) - int32_t offset : 30; - uint32_t type : 2; -# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ -# elif defined(__BIG_ENDIAN_BITFIELD) - uint32_t type : 2; - int32_t offset : 30; -# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ -# elif defined(__LITTLE_ENDIAN_BITFIELD) - int32_t offset : 30; - uint32_t type : 2; -# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ -# else -# error "Unknown bitfield order for flat files." -# endif - } reloc; -} flat_v2_reloc_t; -``` - -在 version 4 中，重定位类型被去掉，一个条目就是一个偏移量（以 0 为基）。各偏移量在重定位时依靠与程序各段起始/结束位置（例如 entry、data_start、data_end、bss_end）进行比较来确定其所处的程序段。 - -### ELF 文件格式 - -ELF 文件结构如下图所示：（这边改成文件夹下的 elf.png） - -ELF 文件格式的 header 有 32bit 和 64bit 两个版本，这边给出 32bit 的版本： - -```c -#define EI_NIDENT 16 - -typedef struct elf32_hdr{ - unsigned char e_ident[EI_NIDENT]; - Elf32_Half e_type; - Elf32_Half e_machine; - Elf32_Word e_version; - Elf32_Addr e_entry; /* Entry point */ - Elf32_Off e_phoff; - Elf32_Off e_shoff; - Elf32_Word e_flags; - Elf32_Half e_ehsize; - Elf32_Half e_phentsize; - Elf32_Half e_phnum; - Elf32_Half e_shentsize; - Elf32_Half e_shnum; - Elf32_Half e_shstrndx; -} Elf32_Ehdr; -``` - -64bit 版本的 header 与 32bit 版本的 header 基本相同，区别仅仅是字长的区别 - -header 中的 e_ident 字段用于标识文件类型，是一个 16 字节的表示，其中前四个字节为魔数，取值是固定的`0x7f`、`'E'`、`'L'`、`'F'`，[4,4]字节为文件类型，[5,5]字节为字长，[6,6]字节为字节序，[7,7]字节为版本号，[8,15]字节为保留字节。 - -e_type 字段标识文件类型，e_machine 字段标识目标文件体系结构，e_version 是当前文件的版本，e_entry 是程序入口地址，e_phoff 是程序头表的偏移量，e_shoff 是节头表的偏移量，e_flags 是特定于目标文件的标志，e_ehsize 是 elf header 的大小，e_phentsize 是程序头表中每个条目的大小，e_phnum 是程序头表中条目的数量，e_shentsize 是节头表中每个条目的大小，e_shnum 是节头表中条目的数量，e_shstrndx 是节头表中节名称字符串表的索引。 - -e_type 字段决定了 ELF 文件的类型如下三种： - -* 可重定位文件（relocatable file）：包含可重定位的目标文件，可以用于链接生成可执行文件或者共享目标文件。 -* 可执行文件（executable file）：包含可执行的目标文件，可以直接被加载到内存中执行。 -* 共享目标文件（shared object file）：包含共享目标文件，可以被动态加载到内存中。 - -ELF 的节头表是节头数组。每一个节头描述其信息。sh_name 字段为节名，sh_type 字段为节类型，sh_flags 字段为节标志，sh_addr 字段为节的虚拟地址，sh_offset 字段为节的偏移量，sh_size 字段为节的大小，sh_link 字段为节头表索引，sh_info 字段为节头表索引，sh_addralign 字段为节的对齐要求，sh_entsize 字段为节头表中每个条目的大小。 - -除此之外，节中比较特殊的是如符号表，重定位表等。 - -### 重定位 - -bFLT 文件一般而言是 PIC 的，执行之前需要由加载器进行重定位。重定位有两种，一种是对全局/静态指针的重定位，一种是对 GOT 表的重定位。这两种重定位在没有 XIP 时使用相同的方法，即将程序基址直接加上偏移量。如果需要处理代码段和数据段不连续的情况以实现 XIP，可以通过如下方法确定偏移量所属程序段： - -```c -if (offset < (data_start - entry)) { - //pointing to code section -} else if (offset < (data_end - entry)) { - //pointing to data section -} else if (offset < (bss_end - entry)) { - //pointing to bss section -} -``` - -BFLT 文件通常是没有显式的重定位表的，而 ELF 文件的重定位信息被包含在其重定位表重，在加载 ELF 文件时，操作系统通过解析重定位表的信息，根据需要修正符号引用，以适应实际内存布局。这里的重定位也是支持不同类型的，绝对地址和相对地址都可以被使用。 - -总的来说，其在重定位的不同是他们的复杂性和灵活性的不同的决定因素。ELF 文件用更规范也更复杂的重定位方式，而 bFLT 文件则使用更简单，更紧凑的重定位方式。 - -### 共享库 - -bFLT 对共享库的链接在编译时而非运行时被决定，这点不同于带有 MMU 的系统。但是，程序在加载时仍然需要对共享库链接进行重定位。 - -共享库的重定位条目由两个部分组成：共享库的编号和所引用符号在共享库中的偏移。其中，共享库编号范围是 0~255，占用最高字节。例如，一个共享库的重定位条目为`0x030003a0`，表明该重定位条目指向编号为`0x03`的共享库当中偏移量相对于共享库为`0x03a0`的符号。如果该共享库被加载进`0x2000`，而使用该库的程序被加载进`0x1000`，那么该符号重定位后的绝对地址应当是 0x23a0。 - -而 ELF 文件支持动态链接，在运行时可以加载共享库而不需要将他们完全静态链接到可执行文件中，这样可以减少可执行文件的大小。ELF 文件的动态链接是通过动态链接器（dynamic linker）来实现的，动态链接器是一个独立的可执行文件，它在程序加载时被调用，负责加载共享库并进行重定位。 - -### 总结 - -总结来说，通过上文对 ELF 和 bFLT 的文件从头，结构，重定位和共享库的解析，其实可以看出其区别主要在于： - -1. 通用性：ELF 文件格式是通用的，而 bFLT 文件格式是针对嵌入式系统。 -2. 功能复杂性：ELF 文件格式支持动态链接，共享库，多种重定位类型，而 bFLT 文件格式更简单紧凑。 -3. 资源效率：BFLT 文件紧凑简单，对资源的利用率高，更适合资源有限的嵌入式系统。ELF 文件元数据更多，对资源的利用率低，更适合资源充足的系统。 +> Corrector: [TinyCorrect](https://gitee.com/tinylab/tinycorrect) v0.2-rc2 - [codeinline urls refs pangu autocorrect]
+> Author: Odysseus <320873791@qq.com>
+> Date: 2023/09/19
+> Revisor: walimis <>
+> Project: [RISC-V Linux 内核剖析](https://gitee.com/tinylab/riscv-linux)
+> Proposal: [为 ELF2FLT 完善独立编译与安装支持](https://gitee.com/tinylab/riscv-linux/issues/I79PO2)
+> Sponsor: PLCT Lab, ISCAS + +# ELF 和 FLAT 的区别 + +## 简介 + +bFLT 是一种用于嵌入式系统的可执行文件格式，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 + +而 FLAT 的二进制文件通常成为 BFLT，是基于原始的 ELF 文件格式的一种简化版本，它的特点是简单、紧凑，适合于资源有限的嵌入式系统。 + +ELF 的头较为重量级，bflt 格式对文件头和一些段信息进行了简化。ELF 支持动态加载，因此更统一使用和创建动态链接库。而 FLAT 并不支持动态加载。 + +接下来我们主要从头文件和重定位的方式解析两种格式的区别。 + +## bflt 程序结构 + +bflt 格式的结构如下： + +![uclinux_file_bflt](images/20230919-elf2flt-flt-analysis-0/bflt-structure.png) + +其中，header 由以下结构体定义： + +```c +struct flat_hdr { + char magic[4]; + uint32_t rev; /* version */ + uint32_t entry; /* Offset of first executable instruction with text segment from beginning of file */ + uint32_t data_start; /* Offset of data segment from beginning of file */ + uint32_t data_end; /* Offset of end of data segment from beginning of file */ + uint32_t bss_end; /* Offset of end of bss segment from beginning of file */ + + /* (It is assumed that data_end through bss_end forms the bss segment.) */ + + uint32_t stack_size; /* Size of stack, in bytes */ + uint32_t reloc_start; /* Offset of relocation records from beginning of file */ + uint32_t reloc_count; /* Number of relocation records */ + uint32_t flags; + uint32_t build_date; /* When the program/library was built */ + uint32_t filler[5]; /* Reserved, set to zero */ +}; +``` + +如上，bflt 的 header 只有 19 个字节。 +header 以由"bFLT"四个字符组成的幻数开头。下一个字段 rev 表明 bflt header 的版本。目前而言，bflt 有两个主要的大版本（version 2 和 version 4），不同的 bflt 版本支持的 flags 和重定位格式都有所不同。 + +接下来的字段标记程序各段的起始/结束位置：entry 为程序执行的第一条指令，也就是.text 段的起始位置；data_start 和 data_end 标示.data 段的起始/结束位置；bss_end 标示.bss 段的结束位置，bflt header 并未标示 bss_start，而是假定从 data_end 到 bss_end 都为.bss 段；stack_size 指定栈空间大小；reloc_start 和 reloc_count 共同决定重定位表的范围，其中 reloc_start 标示起始位置，reloc_count 表明重定位条目数。 + +flags 字段可能的取值如下： + +```c +#define FLAT_FLAG_RAM 0x0001 /* load program entirely into RAM */ +#define FLAT_FLAG_GOTPIC 0x0002 /* program is PIC with GOT */ +#define FLAT_FLAG_GZIP 0x0004 /* all but the header is compressed */ +#define FLAT_FLAG_GZDATA 0x0008 /* only data/relocs are compressed (for XIP) */ +#define FLAT_FLAG_KTRACE 0x0010 /* output useful kernel trace for debugging */ +#define FLAT_FLAG_L1STK 0x0020 /* use a 4k stack in L1 scratch memory. */ +``` + +其中前三个 flag 是 version 4 新增的。FLAT_FLAG_RAM 表明程序不是 XIP 的，执行时会完全加载进内存；FLAT_FLAG_GOTPIC 表明程序是有 GOT 表的 PIC 程序，此时程序.data 段的开头有一张 GOT 表，该表以 -1 结尾，包含需要在运行时重定位的偏移量，用以实现动态链接。 + +重定位表由重定位条目组成。在 version 2 中，重定位条目定义如下： + +```c +#define OLD_FLAT_VERSION 0x00000002L +#define OLD_FLAT_RELOC_TYPE_TEXT 0 +#define OLD_FLAT_RELOC_TYPE_DATA 1 +#define OLD_FLAT_RELOC_TYPE_BSS 2 + +typedef union { + uint32_t value; + struct { +# if defined(mc68000) && !defined(CONFIG_COLDFIRE) + int32_t offset : 30; + uint32_t type : 2; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# elif defined(__BIG_ENDIAN_BITFIELD) + uint32_t type : 2; + int32_t offset : 30; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# elif defined(__LITTLE_ENDIAN_BITFIELD) + int32_t offset : 30; + uint32_t type : 2; +# define OLD_FLAT_FLAG_RAM 0x1 /* load program entirely into RAM */ +# else +# error "Unknown bitfield order for flat files." +# endif + } reloc; +} flat_v2_reloc_t; +``` + +在 version 4 中，重定位类型被去掉，一个条目就是一个偏移量（以 0 为基）。各偏移量在重定位时依靠与程序各段起始/结束位置（例如 entry、data_start、data_end、bss_end）进行比较来确定其所处的程序段。 + +## ELF 文件格式 + +ELF 文件结构如下图所示：（这边改成文件夹下的 elf.png） + +ELF 文件格式的 header 有 32bit 和 64bit 两个版本，这边给出 32bit 的版本： + +```c +#define EI_NIDENT 16 + +typedef struct elf32_hdr{ + unsigned char e_ident[EI_NIDENT]; + Elf32_Half e_type; + Elf32_Half e_machine; + Elf32_Word e_version; + Elf32_Addr e_entry; /* Entry point */ + Elf32_Off e_phoff; + Elf32_Off e_shoff; + Elf32_Word e_flags; + Elf32_Half e_ehsize; + Elf32_Half e_phentsize; + Elf32_Half e_phnum; + Elf32_Half e_shentsize; + Elf32_Half e_shnum; + Elf32_Half e_shstrndx; +} Elf32_Ehdr; +``` + +64bit 版本的 header 与 32bit 版本的 header 基本相同，区别仅仅是字长的区别 + +header 中的 e_ident 字段用于标识文件类型，是一个 16 字节的表示，其中前四个字节为魔数，取值是固定的 `0x7f`、`'E'`、`'L'`、`'F'`，[4,4] 字节为文件类型，[5,5] 字节为字长，[6,6] 字节为字节序，[7,7] 字节为版本号，[8,15] 字节为保留字节。 + +e_type 字段标识文件类型，e_machine 字段标识目标文件体系结构，e_version 是当前文件的版本，e_entry 是程序入口地址，e_phoff 是程序头表的偏移量，e_shoff 是节头表的偏移量，e_flags 是特定于目标文件的标志，e_ehsize 是 elf header 的大小，e_phentsize 是程序头表中每个条目的大小，e_phnum 是程序头表中条目的数量，e_shentsize 是节头表中每个条目的大小，e_shnum 是节头表中条目的数量，e_shstrndx 是节头表中节名称字符串表的索引。 + +e_type 字段决定了 ELF 文件的类型如下三种： + +* 可重定位文件（relocatable file）：包含可重定位的目标文件，可以用于链接生成可执行文件或者共享目标文件。 +* 可执行文件（executable file）：包含可执行的目标文件，可以直接被加载到内存中执行。 +* 共享目标文件（shared object file）：包含共享目标文件，可以被动态加载到内存中。 + +ELF 的节头表是节头数组。每一个节头描述其信息。sh_name 字段为节名，sh_type 字段为节类型，sh_flags 字段为节标志，sh_addr 字段为节的虚拟地址，sh_offset 字段为节的偏移量，sh_size 字段为节的大小，sh_link 字段为节头表索引，sh_info 字段为节头表索引，sh_addralign 字段为节的对齐要求，sh_entsize 字段为节头表中每个条目的大小。 + +除此之外，节中比较特殊的是如符号表，重定位表等。 + +## 重定位 + +bFLT 文件一般而言是 PIC 的，执行之前需要由加载器进行重定位。重定位有两种，一种是对全局/静态指针的重定位，一种是对 GOT 表的重定位。这两种重定位在没有 XIP 时使用相同的方法，即将程序基址直接加上偏移量。如果需要处理代码段和数据段不连续的情况以实现 XIP，可以通过如下方法确定偏移量所属程序段： + +```c +if (offset < (data_start - entry)) { + //pointing to code section +} else if (offset < (data_end - entry)) { + //pointing to data section +} else if (offset < (bss_end - entry)) { + //pointing to bss section +} +``` + +BFLT 文件通常是没有显式的重定位表的，而 ELF 文件的重定位信息被包含在其重定位表重，在加载 ELF 文件时，操作系统通过解析重定位表的信息，根据需要修正符号引用，以适应实际内存布局。这里的重定位也是支持不同类型的，绝对地址和相对地址都可以被使用。 + +总的来说，其在重定位的不同是他们的复杂性和灵活性的不同的决定因素。ELF 文件用更规范也更复杂的重定位方式，而 bFLT 文件则使用更简单，更紧凑的重定位方式。 + +## 共享库 + +bFLT 对共享库的链接在编译时而非运行时被决定，这点不同于带有 MMU 的系统。但是，程序在加载时仍然需要对共享库链接进行重定位。 + +共享库的重定位条目由两个部分组成：共享库的编号和所引用符号在共享库中的偏移。其中，共享库编号范围是 0~255，占用最高字节。例如，一个共享库的重定位条目为 `0x030003a0`，表明该重定位条目指向编号为 `0x03` 的共享库当中偏移量相对于共享库为 `0x03a0` 的符号。如果该共享库被加载进 `0x2000`，而使用该库的程序被加载进 `0x1000`，那么该符号重定位后的绝对地址应当是 0x23a0。 + +而 ELF 文件支持动态链接，在运行时可以加载共享库而不需要将他们完全静态链接到可执行文件中，这样可以减少可执行文件的大小。ELF 文件的动态链接是通过动态链接器（dynamic linker）来实现的，动态链接器是一个独立的可执行文件，它在程序加载时被调用，负责加载共享库并进行重定位。 + +## 总结 + +总结来说，通过上文对 ELF 和 bFLT 的文件从头，结构，重定位和共享库的解析，其实可以看出其区别主要在于： + +1. 通用性：ELF 文件格式是通用的，而 bFLT 文件格式是针对嵌入式系统。 +2. 功能复杂性：ELF 文件格式支持动态链接，共享库，多种重定位类型，而 bFLT 文件格式更简单紧凑。 +3. 资源效率：BFLT 文件紧凑简单，对资源的利用率高，更适合资源有限的嵌入式系统。ELF 文件元数据更多，对资源的利用率低，更适合资源充足的系统。 + +## 参考资料 + +-. [http://myembeddeddev.blogspot.com/2010/02/uclinux-flat-file-format.html][001] +-. [https://blog.tangrs.id.au/2012/04/07/bflt-format-implementation-notes/][002] +-. [https://gitee.com/tinylab/elf2flt][003] + +[001]: http://myembeddeddev.blogspot.com/2010/02/uclinux-flat-file-format.html +[002]: https://blog.tangrs.id.au/2012/04/07/bflt-format-implementation-notes/ +[003]: https://gitee.com/tinylab/elf2flt -- Gitee