[英]Different types of object files
ELF 文檔中的e_type
列出了以下可用的目標文件類型:
Name Value Meaning
ET_NONE 0 No file type
ET_REL 1 Relocatable file
ET_EXEC 2 Executable file
ET_DYN 3 Shared object file
ET_CORE 4 Core file
ET_LOPROC 0xff00 Processor-specific
ET_HIPROC 0xffff Processor-specific
我在哪里可以詳細了解這些文件類型是什么? 例如,我從來沒有聽說過“特定於處理器”的文件:有什么例子呢?
在執行$ xxd -l 32 /bin/ls
,對象類型為 ET_DYN:
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............
00000010: 0300 <-- object type = 3 or "shared object file"
為什么ls
不被視為可執行文件,而是共享對象? (編者注:這部分是為什么 GCC 根據文件創建共享對象而不是可執行二進制文件的readelf -h /bin/ls
?此外, readelf -h /bin/ls
是解碼 ELF 標頭的更簡單方法,包括 ELF 類型)
最后,什么是core
文件? 這像堆棧跟蹤嗎? http://man.netbsd.org/core.5 , 使用C從core dump中獲取導致segmentation fault的地址。
(編者注:這部分是什么是 Linux 中的核心轉儲文件?它提供什么信息?不幸的是,這是 1 個帖子中的 3 個問題,因此在回答非重復部分時不能輕易標記為重復部分)
你的問題有兩個部分:
如果未來的 CPU 系列想要定義新類型的文件,這些將作為“擴展點”。 沒有一個主要的處理器系列使用過這個范圍內的東西,所以即使稍微搜索一下,我也找不到任何例子。
ls
是ET_DYN
ET_DYN
常量僅表示該對象是運行時可重定位的。 傳統上,這已用於共享對象 ( .so
),但對於 glibc 中的位置無關可執行文件 (PIE),它們重用與共享對象相同的編譯器和加載器代碼來進行運行時重定位,從而導致這種混亂的情況其中可執行文件被報告為共享對象。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.