• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 71,  comments - 41,  trackbacks - 0
            上一篇文章介紹了COFF目標文件的結構。如果你試著做一個應用程序的連接器(Linker),就會發現,僅僅有目標文件是不夠的。我們在連接程序時,不僅僅要用到目標文件,庫文件也是必不可少的。
                庫文件是怎么樣的結構呢?
                其實,庫文件的結構也很簡單。它就是“一堆”目標文件的集合。把目標文件做成庫以后,我們在使用目標文件中所實現的功能時,連接程序會自動在庫文件里查找相應的目標文件,并使用它。這大大減少了我們對目標文件的管理工作,減輕了代碼重用的負擔。
                Lib文件中的節
                COFF格式中所用到的“節”的概念再次出現在Lib格式中。不過,Lib文件的節要簡單得多。先讓我們來看看它的整體結構:
                如右圖所示:
                Lib格式只有四種類型的節(Section),即First Sec,Second Sec,Longname Sec和Obj Sec;其中Second Sec與Longname Sec是可選節,很多Lib文件中都沒有。而開頭的Singature只是一個標識,它相當于COFF目標文件中的魔法數字。它是一個長度為8的字符串,值為“!<arch>\n”。
                First Sec,顧名思義,就是第一個節。它包含了庫中所有的符號名以及這些符號所在的目標文件在庫中的位置(絕對偏移)。
                Second Sec就是第二節。它的內容和First Sec是相同的。不同的是,Second Sec是一個有序表,通過它來查找庫中的符號比通過First Sec來查找要快很多。
            Signature
            First Sec
            Second Sec
            Longname Sec
            Obj Sec1
            Obj Sec2
            ……










                Longname Sec是長名稱節。這一節是一個字符串表。它包含了所有長目標文件名。如果后面的Obj Sec中沒有給出相應的目標文件名,我們就要到這一節中來查找。
                Obj Sec就是目標文件節。這些節中存儲著不同的目標文件的原始數據。
             
                在庫文件中,每一節都有兩個部分。一個部分是頭,另一個部分才是該節的數據;數據緊跟在頭的后面。頭描述了該節數據的類型、長度等信息。這些頭的格式都是相同的。其結構用C語言描述如下:
                typedef struct {
                    char Name[16];      // 名稱
                    char Time[12];      // 時間
                    char UserID[6];     // 用戶ID
                    char GroupID[6];    // 組ID
                    char Mode[8];       // 模式
                    char Size[10];      // 長度
                    char EndOfHeader[2];// 結束符
                } SectionHeader;
                可以看到,頭中的數據全都是字符串。用字符串的好處是可以提高格式的兼容性,因為在不同的機器上,數據的排列方式是不同的。有的機器是以Little-Endian方式工作,還有的是以Big-Endian方式工作,它們互不兼容(這兩種方式的區別!?請看我的《COFF格式》一文,其中的文件頭一節有說明)。用字符串就不會有這種問題(后面我們將會遇到)。但它也有不方便的地方,就是必須把字符串轉換成數值,多了一個步驟。
                在這個結構中,最常用的Name、Size以及EndOfHeader三個成員。Name就是節的名稱啦!Size也很好理解,就是該節數據的長度。現在要注意的就是這個EndOfHeader成員了!這個成員標志著頭的結束,其內容為“`\n”(注意,這里沒有打錯,是兩個字符“`”和“\n”)。怎么樣?有點奇怪吧?為什么要有這個結束符?每一節的頭長度一定,每節中的數據長度也知道。按順序向下讀不行嗎?答案是:不行!因為每一節之間存在間隙!通常是一個字節或零個字節。如果是零個字節倒好,按順序向下讀是OK的。可是如果不為零的話,這樣讀就要錯位了。要知道錯位沒有,只好用一個結束符來定位了。如果在讀頭的時候發現結束符不對,那就要一個字節一個字節地向下查找,直到找到結束符,才能算是對齊了。切記!切記!
                當然,通過First Sec或Second Sec中給出的偏移來讀數據就不存在這個問題。不會發生錯位,放心讀吧!
                現在讓我們來看看每一節中的數據是什么樣子。
             
                First Sec
                第一節,通常就是Lib中的每一個小節。它的名稱是“/”。其數據部分的結構如下:
                typedef struct {
                    unsigned long SymbolNum;         // 庫中符號的數量
                    unsigned long SymbolOffset[n];   // 符號所在目標節的偏移
                    char StrTable[m];                // 符號名稱字符串表
                }FirstSec;
                第一個成員SymbolNum是符號的數量。注意!它是以Big-Endian方式儲存的(x86平臺上的數據是以Little-Endian方式儲存的。這里應該注意轉換。后面給出的convert函數可以在Little-Endian格式與Big-Endian格式之間進行相互轉換)。
                第二個成員SymbolOffset是一個數組,它的長度n就是符號的數量,也就是SymbolNum。這個數組儲存了每一個符號所在的目標節的偏移。我們可以方便地通過它來查找符號所在的目標文件。注意!它也是以Big-Endian格式儲存的。
                第三個成員StrTable是一個字符串表,它的長度m就是SectionHeader.Size的值減去(SymbolNum+1)*4。其結構很簡單,就是一堆以‘\0’結尾的字符串(和COFF文件中的字符串表結構相同)。在有的系統中,它還可能是以“/\n”這兩個字符結尾的字符串的集合。
                很簡單的一個結構,不過有兩個成員的長度是不定的。怎么才能方便地從Lib中讀出這些數據,留給大家自己想吧!下面我只給出一個進行Little-Endian與Big-Endian互轉的函數。
                inline void convert(void * p          // 要轉換的數據的指針
                                    ,size_t size = 4  // 數據的長度,long為4,short為2
                                    ) {
                    char * buf=(char*)p;
                    char temp;
                    for ( size_t i=0;i<size/2;i++ ) {
                        temp=buf[i];
                        buf[i]=buf[size-i-1];
                        buf[size-i-1]=temp;
                    }
                }
             
            Second Sec
                現在看看第二節。
                這一節與第一節很相似!它通常也就是Lib文件的第二個節。它的名字也是“/”(注意:文件中第一個叫“/”的節是第一節,第二個就是第二節)。不過它的結構與第一節有些不同,如下:
                typedef struct {
                    unsigned long ObjNum;        // Obj Sec的數量
                    unsigned long ObjOffset[x];  // 每一個Obj Sec的偏移
                    unsigned long SymbolNum;     // 庫中符號的數量
                    unsigned short SymbolIdx[n]; // 符號在ObjOffset表中的索引
                    char StrTable[m];            // 符號名稱字符串表
                }SecondSec;
                第一個成員ObjNum是庫中Obj Sec的數量。
                第二個成員ObjOffset是一個偏移表,它記錄了庫中所有Obj Sec的偏移。這個表的記錄數x就是ObjNum。
                第三個成員SymbolNum與First Sec中的SymbolNum意義相同。
                第四個成員SymbolIdx變成了一個索引,它記錄了相應名稱字符串在ObjOffset這個表中的位置,我們要通過兩次索引才能找到我們所要符號的Obj Sec位置。它的項目數n為SymbolNum。但請注意,這個索引是unsigned short型,不再是unsigned long型。
                第五個成員StrTable結構與First Sec中的一樣。不過,它的長度m為SectionHeader.Size的值減去((ObjNum+1)*4+(SymbolNum+2)*2)。
                值得注意的是,這里的所有數據都是Little-Endian格式的。千萬不要弄錯了!

            Longname Sec
                這個小節就是一個字符串表,它的名稱為“//”,其結構同FirstSec.StrTable。這里就不多說了。

            Obj Sec

                這一節中的數據就是COFF文件的原始數據,把它讀出來存成文件,就是一個COFF文件。它的格式請參考《COFF格式》一文。
                要指出的是它的命名方式有些特殊。如果Obj文件的名稱少于16個字符,它就會被保存在SectionHeader的Name成員中,以‘/’字符結尾。如果無法保存在Name成員中,則Name成員的第一個字符就為‘/’,之后再跟上這個名稱在Longname Sec中的偏移。

            例如

            !<arch>\n
            ……
            LongName Sec:
            This_Is_Long_Name0001\0
            This_Is_Long_Name0002\0
            ……
            Obj Sec1:
             Name[16]:“shortname/”
             ……
            Obj Sec2:
             Name[16]:“/0”  // 這里使用了第一個長文件名This_Is_Long_Name0001
             ……
            Obj Sec3:
             Name[16]:“/22”  // 這里使用了第二個長文件名This_Is_Long_Name0002
             ……
             
                OK!現在已經介紹完了Lib文件的結構。大家的連接器可以加新功能了。不過這里只給出了最基本的Lib文件結構,動態連接庫(DLL)的導出庫有點特別,我將在PE文件格式中進行詳細介紹。
            posted on 2007-07-19 16:54 Charles 閱讀(2250) 評論(1)  編輯 收藏 引用 所屬分類: 拿來主義

            FeedBack:
            # re: COFF格式續篇—Lib文件的結構zz[未登錄]
            2007-07-20 01:07 | Corner Zhang
            好文!
            期待關于dll的  回復  更多評論
              
            <2007年7月>
            24252627282930
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            決定開始寫工作日記,記錄一下自己的軌跡...

            常用鏈接

            留言簿(4)

            隨筆分類(70)

            隨筆檔案(71)

            charles推薦訪問

            搜索

            •  

            積分與排名

            • 積分 - 50431
            • 排名 - 449

            最新評論

            閱讀排行榜

            評論排行榜

            丁香色欲久久久久久综合网| 91精品日韩人妻无码久久不卡| 国产精品99久久99久久久| 国产亚洲成人久久| 91久久九九无码成人网站| 久久91精品国产91久久户| 国产精品禁18久久久夂久| 77777亚洲午夜久久多人| 久久久久久曰本AV免费免费| 亚洲欧美成人久久综合中文网| 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区 | 久久人人爽人人精品视频| 亚洲国产成人久久综合碰碰动漫3d | 办公室久久精品| 777久久精品一区二区三区无码| 东京热TOKYO综合久久精品| 麻豆成人久久精品二区三区免费| 国产美女亚洲精品久久久综合| 久久婷婷五月综合97色直播| 亚洲精品无码专区久久久 | 久久香综合精品久久伊人| 久久这里的只有是精品23| 久久久久久久波多野结衣高潮| 久久久久av无码免费网| 久久精品国产亚洲av麻豆色欲 | 色播久久人人爽人人爽人人片aV| 思思久久99热免费精品6| 久久午夜无码鲁丝片秋霞 | 日本免费一区二区久久人人澡| 久久99免费视频| 狠狠色丁香婷婷久久综合| 婷婷综合久久中文字幕蜜桃三电影| 狠狠色婷婷综合天天久久丁香 | 国产精品成人无码久久久久久| 欧美久久一区二区三区| 久久婷婷五月综合97色| 久久er国产精品免费观看8| 久久精品aⅴ无码中文字字幕不卡 久久精品成人欧美大片 | 婷婷五月深深久久精品| 伊人色综合久久天天| 亚洲国产美女精品久久久久∴ |