GNU ARM匯編的.balignl對齊實(shí)驗
加入技術(shù)交流群
.balignl與. align類(lèi)似，完整的laign語(yǔ)句格式為：.align {alignment} {,fill} {,max}
本文引用地址：http://dyxdggzs.com/article/201611/319126.htmalignment用于指定對齊方式，可能的取值為2的次冪，缺省為4。fill是填充內容，缺省用0填充。max是填充字節數最大值，如果填充字節數超過(guò)max, 不進(jìn)行對齊。
下面分4種情況進(jìn)行對比：
1.正常情況
.word 0x12345678
.global _end_vect
_end_vect:
.balignl 16,0xdeadbeef
此時(shí).balignl位于的地址是0x50，恰好是16的倍數，所以不填充。如圖所示：
2.填充一個(gè)字
//.word 0x12345678
.global _end_vect
_end_vect:
.balignl 16,0xdeadbeef
此時(shí)將0x12345678注釋掉，.balignl位于的地址是0x4c，不是16的倍數，所以要使用0xdeadbeef進(jìn)行填充。如圖所示：
3.填充三個(gè)字
.word 0x12345678
.word 0x12345678
.global _end_vect
_end_vect:
.balignl 16,0xdeadbeef
此時(shí)加多一個(gè)0x12345678，使.balignl的地址位于0x54，不是16的倍數，所以要填充到0x5f，內容使用指定的0xdeadbeef。如圖所示：
4.超過(guò)限制不填充
.word 0x12345678
.word 0x12345678
.global _end_vect
_end_vect:
.balignl 16,0xdeadbeef,8
此時(shí)限制填充最多8個(gè)字節，但是需要填充12個(gè)字節，所以不填充。如圖所示：
補充：
.balignl 16,0xdeadbeef 是uboot起始文件下的start.S文件57行. 因為好奇這個(gè)代碼的含義,所以百度了下: ==================================================== (http://haoyeren.blog.sohu.com/84511571.html) 先要弄明白.balignl的意思，這個(gè)其實(shí)應該算是一個(gè)偽操作符，偽操作符的意思就是機器碼里，并沒(méi)有一個(gè)匯編指令與其對應，是編譯器來(lái)實(shí)現其功能的。.balignl是.balign的變體，.balign是意思是，在以當前地址開(kāi)始，地址計數器必須是以第一個(gè)參數為整數倍的地址為尾，在前面記錄一個(gè)字節長(cháng)度的信息，信息內容為第二個(gè)參數。 .balign 8, 0xde 它的意思就是在以當前地址開(kāi)始，在地址為8的倍數的位置的前面填入一個(gè)字節內容為0xde的內容。如果當前地址正好是8的倍數，則沒(méi)有東西被寫(xiě)入到內存。 ======================================================= http://blog.163.com/mcu_expert/blog/static/131245153201073125947792 關(guān)于.balignl 16,0xdeadbeef這句，功能說(shuō)明沒(méi)有錯，就是想在某個(gè)位置插入0xdeadbeef這個(gè)特殊的內存值。錯就錯在我對這個(gè)16的理解上面。16是 16個(gè)字節，這是沒(méi)有錯的，但是這個(gè)16的由來(lái)，并不是我所理解的得至少為16個(gè)字節，才能在任何情況下保證插入這個(gè)特殊的內存值。我在此篇博客的留言中，回答某位網(wǎng)友的提問(wèn)，舉了個(gè)pc為0x00000007地址，偏移量某為8字節時(shí)，這個(gè)時(shí)候就不夠4字節的內容了，以此推導出的，至少有16個(gè)字節才能保證這個(gè)特殊的內存值的插入也是完全錯誤的。 舉個(gè)反例，如果按給那位網(wǎng)友的解釋?zhuān)蔷退阌?6個(gè)字節的偏移量，那如果pc地址為0x0000000F時(shí)，也只有一個(gè)字符的空間，那這個(gè)deadbeef的值還是不夠。以此類(lèi)推，就算這個(gè)值為任意一值，按我之前解釋的錯誤邏輯，也都是有不滿(mǎn)足的情況的，呵呵。所以我之前的推論有誤，特此更正。我現在把16這個(gè)值的由來(lái)進(jìn)行說(shuō)明。 ARM920T處理器核心，支持32位與16位兩種指令長(cháng)度，16位的指令叫thumb指令集，由于我使用的是32位指令集，所以一切都是以32位指令集進(jìn)行說(shuō)明。 既然是32位指令集，所以一條指令就占32位，即4字節，所以在調試器中，地址的顯示也是4字節一跳的（調試器的截圖在這篇博文的評論中有鏈接），所以pc的值，也是4字節一跳的，并不存在可能pc的值為0x00000007的情況，呵呵。 這個(gè)地方填16個(gè)偏移量，是因為 .globl _start //不占內存 占了4x8=32字節內存。 _undefined_instruction: .word undefined_instruction //占4字節內存 占了4x7=28字節內存。 所以在這個(gè).balignl 16,0xdeadbeef指令之前，一共占了4x15=60個(gè)字節的內存，所以本代碼的作者當時(shí)就簡(jiǎn)單的在15這個(gè)數上，加了個(gè)1，即16，把當前指針往后移到地址為64的位置，然后在前面插上了0xdeadbeef這個(gè)特殊的值。 我不知道這個(gè)地方是作者一個(gè)錯誤，歪打正著(zhù)呢，還是怎么回子事，其實(shí)這個(gè)偏移的值還有好多種情況。如果說(shuō)最小的值的話(huà)，那么也可以寫(xiě)成.balignl 8,0xdeadbeef，也可以達到同樣的目的。因為60不是8的倍數，但是64是8的倍數 (60到64之間都不是8的倍數,同樣也不是16的倍數,所以寫(xiě)8和16都可行)，如果寫(xiě)8，也正好插到64前面，也即60這個(gè)內存起始地址。如果更大一點(diǎn)兒的呢，那么填32也可以達到同樣的效果，即.balignl 32,0xdeadbeef，道理同上。當然，不能為4，因為pc值在任何時(shí)候，都是4的倍數 (60是4的倍數)，只要不為0就為4的倍數，呵呵，這個(gè)值不行，如果用了這個(gè)值，0xdeadbeef永遠也插不進(jìn)去，呵呵。 |
評論