如何解决不同类型的目标文件
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
不被视为可执行文件,而是共享对象? (编者注:这部分是Why does GCC create a shared object instead of an executable binary according to file?的副本,此外,readelf -h /bin/ls
是解码ELF标头(包括ELF类型)的更简便方法)
最后,什么是core
文件?这就像一个堆栈跟踪吗? http://man.netbsd.org/core.5,Get the address that caused segmentation fault from core dump using C。
(编者注:这部分是What is a core dump file in Linux? What information does it provide?的重复部分。不幸的是,这是1个帖子中的3个问题,因此在回答非重复部分时不容易将其标记为重复部分)
解决方法
您的问题分为两部分:
特定于处理器的类型
如果将来的CPU系列希望定义一种新的文件类型,这些将保留为“扩展点”。没有一个主要的处理器系列使用过该范围的产品,因此即使经过一点搜索,也无法提供示例。
ls
是ET_DYN
ET_DYN
常量仅表示该对象可在运行时重定位。传统上,它已用于共享库(.so
),但是对于glibc中的位置无关可执行文件(PIE),他们重用了与共享库相同的编译器和加载器代码来进行运行时重定位,从而导致这种将可执行文件报告为共享对象的令人困惑的情况。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。