elf | 易学教程

Why an ELF executable could have 4 LOAD segments?

阅读更多关于 Why an ELF executable could have 4 LOAD segments?

问题 There is a remote 64-bit *nix server that can compile a user-provided code (which should be written in Rust, but I don't think it matters since it uses LLVM). I don't know which compiler/linker flags it uses, but the compiled ELF executable looks weird - it has 4 LOAD segments: $ readelf -e executable ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align ... LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000004138 0x0000000000004138 R 0x1000

Why would the ELF header of a shared library specify Linux as the OSABI?

阅读更多关于 Why would the ELF header of a shared library specify Linux as the OSABI?

问题 All the standard shared libraries on my Linux system (Fedora 9) specify ELFOSABI_NONE (0) as their OSABI. This is fine - however I've received a shared library from a supplier where the OSABI given in the ELF header is ELFOSABI_LINUX (3). This doesn't sound like an unreasonable value for a shared library intended for a Linux system, however it is a different value to that of all my other libraries - and so when I try to open this library, with dlopen(), from one of my other libraries this

Why do Compilers put data inside .text(code) section of the PE and ELF files and how does the CPU distinguish between data and code?

阅读更多关于 Why do Compilers put data inside .text(code) section of the PE and ELF files and how does the CPU distinguish between data and code?

问题 So i am referencing this paper : Binary Stirring: Self-randomizing Instruction Addresses of Legacy x86 Binary Code https://www.utdallas.edu/~hamlen/wartell12ccs.pdf Code interleaved with data: Modern compilers aggressively interleave static data within code sections in both PE and ELF binaries for performance reasons. In the compiled binaries there is generally no means of distinguishing the data bytes from the code. Inadvertently randomizing the data along with the code breaks the binary,

Force GNU linker to generate 32 bit ELF executables

阅读更多关于 Force GNU linker to generate 32 bit ELF executables

问题 Hi I am currently generating x86 assembly for a compiler that I am writing and am having some trouble linking the file on my 64-bit VM (the assembly code is 32 bit). I was able to assemble the object file fine with this command: as --32 mult.S -o mult.o but I can't seem to find any options for ld that make it generate a 32-bit ELF file: ld <some-option?> mult.o -o mult Any help would be great. 回答1: ld <some-option?> mult.o -o mult ld -m elf_i386 mult.o -o mult You can get a list of available

Force GNU linker to generate 32 bit ELF executables

阅读更多关于 Force GNU linker to generate 32 bit ELF executables

Creating ELF instead of a.out

阅读更多关于 Creating ELF instead of a.out

问题 I need to generate a simple "Hello World" ELF32 executable using gcc. I don't seem to have the gcc-elf command though. Is it possible to create ELF binaries instead of a.out without building gcc again? (I'm assuming it should be possible with some options, but am unsure how to proceed) 回答1: a.out is very old, we're talking kernel version 1.2 of linux. Assuming you are operating on any remotely recent linux platform, you are generating elf executables by default. Use the file command on the

skyeye安装

阅读更多关于 skyeye安装

SkyEye是一个开源软件项目，它是在Linux和Windows平台上实现一个纯软件模拟集成开发环境，模拟常见的嵌入式系统。可以在SkyEye上运行Linux,uClinux以及uC/OS-II等多款嵌入式操作系统和各种系统软件。（1）在ubuntu中最简单的方法当然是使用下面的命令来安装skyeye : sudo apt-get install skyeye （2）下面是从源码来编译skyeye的方法：首先从www.uClinux.org上下载arm-elf-tool，里面包含arm-elf-gcc, arm-elf-ld等工具。可以使用下面的方法来安装： sudo cp XXX/arm-elf-tools-20030314.sh /tmp (XXX是下载完的文件的路径) sudo chmod +x arm-elf-tools-20030314.sh (修改文件的权限) sudo ./arm-elf-tools-20030314.sh 但是上面的安装时出现下面的错误 tail: cannot open `+43' for reading: No such file or directory google得到下面的solution， http://blog.csdn.net/lbsljn/archive/2009/06/30/4308625.aspx 一、直接安装法 1

what does `.rodata.str1.8` section mean in elf file

阅读更多关于 what does `.rodata.str1.8` section mean in elf file

问题 I know the .rodata section stores constant data in an ELF file. However, when I dump an ELF of a kernel module, I notice that there are two extra sections named rodata.str1.8 and rodata.str1.1 . It seems that these two sections store constant variables and strings as well. But what exactly are the differences between these three rodata ? 回答1: It looks like .rodata.str1.1 has strings without alignment requirements, while .rodata.str1.8 must be 8-byte aligned. If you look at an ELF file with

What is the section for uninitialized global data?

阅读更多关于 What is the section for uninitialized global data?

问题 I am a little confused as to where uninitialized global variables go in the ELF file. I have this simple program to test in which sections the variables will be located: const int a = 11; int b = 10; int c; int main() { return 0; } I know that uninitialized global variable should be put into .bss section of ELF file, but objdump -h gives me the following output: Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000000a 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE

What “deleted” means in /proc/$pid/maps?

阅读更多关于 What “deleted” means in /proc/$pid/maps?

问题 I downloaded libhugetlbfs.so and have a simple test source : int glbarr[1024*1024]={0} ; int main() { char * ptr ; ptr = (char *) malloc( 1024 * 1024 * 1 ) ; printf(" press any key to go on \n"); getchar() ; for(int idx=0;idx<100;idx++){ char strtmp[64] = {0} ; sprintf(strtmp,"%020d",idx) ; strcpy( ptr+1024*idx , strtmp ) ; } //for for(int idx=0;idx<100;idx++){ glbarr[idx] = idx ; } printf(" press any key to go on \n"); getchar() ; } // main then set the env : export LD_PRELOAD=libhugetlbfs