elf

Adding section to ELF file

馋奶兔 提交于 2019-11-28 18:51:26
I need to be able to add an arbitrary section to an ELF file. I cannot use GPL code in this program, so BFD is out of the question. I can use libelf/gelf to read sections, but the documentation is fairly sparse for these, and I cannot figure out how to add a section. Does anybody know how to do this? I would rather not write my own ELF code. Mark Rushakoff There's a few (possibly) related answers in this question about ELF file headers . The accepted answer mentioned using objcopy to add sections to an ELF file, and the BSD bintools claims to have a BSD-licensed implementation of objcopy that

which part of ELF file must be loaded into the memory?

被刻印的时光 ゝ 提交于 2019-11-28 18:50:24
An ELF file for executables has a program (segment) header and a section header, which can be seen through readelf -a , here is an example: The two pictures above are section header and program (segment) header, respectively. It can be seen that a segment header is composed of several section headers, which is used for loading program into the memory. Is it only necessary for .text, .rodata, .data, .bss sections to be loaded into the memory? Are all of the other sections in the segment (e.g. .ctors, .dtors .jcr in the 3rd segment) used for aligning? Sections and segments are two different

What do the .eh_frame and .eh_frame_hdr sections store, exactly?

若如初见. 提交于 2019-11-28 18:39:58
I know that, when using languages that support exceptions, such as C++, additional information must be provided to the runtime environment to describe the call frames that must be unwound during the processing of an exception. This information is contained in special sections of the object files, such as .eh_frame and .eh_frame_hdr . But, what kind of data structures are stored in these sections? I mean, can they be read by using any C struct? Do they have anything to do with the .cfi statements (such as .cfi_startproc , .cfi_endproc , .cfi_offset , .cfi_def_cfa_offset , .cfi_personality and

.bin .o .elf文件的关系

风格不统一 提交于 2019-11-28 18:01:15
今天错把.o文件烧写到nand,问了韦老师才知道要烧写.bin文件,实在是惭愧。下面描述下三者之间的关系。 1 .bin文件 .bin文件是linux下可执行文件,相当于windows下的.exe文件。bin文件是二进制文件,里面没有地址标记。 2. o文件 目标文件。相当于windows下的obj文件。 3. elf文件 elf文件可以在linux上运行,但不能在裸机下运行 来源: https://blog.csdn.net/liubinhaoma/article/details/100097962

How are the different segments like heap, stack, text related to the physical memory?

◇◆丶佛笑我妖孽 提交于 2019-11-28 17:05:47
When a C program is compiled and the object file(ELF) is created. the object file contains different sections such as bss, data, text and other segments. I understood that these sections of the ELF are part of virtual memory address space. Am I right? Please correct me if I am wrong. Also, there will be a virtual memory and page table associated with the compiled program. Page table associates the virtual memory address present in ELF to the real physical memory address when loading the program. Is my understanding correct? I read that in the created ELF file, bss sections just keeps the

loading ELF file in C in user space

无人久伴 提交于 2019-11-28 16:26:08
I am trying to load an ELF file compiled with "gcc -m32 test.c -o test.exe" on Linux in a 64 bit x86 environment. I am trying to load that 32bit file (test.exe) inside a user space ELF loader which has the following core logic (32bit ELF). The problem is that calling into the returned start address results in a segmentation fault core dump. Here is the code: void *image_load (char *elf_start, unsigned int size) { Elf32_Ehdr *hdr = NULL; Elf32_Phdr *phdr = NULL; unsigned char *start = NULL; Elf32_Addr taddr = 0; Elf32_Addr offset = 0; int i = 0; unsigned char *exec = NULL; Elf32_Addr estart = 0

Floating point exception ( SIGFPE ) on 'int main(){ return(0); }'

霸气de小男生 提交于 2019-11-28 15:54:40
问题 I am trying to build a simple C program for two different Linux environments. On one device the program runs fine, on the other device the program generates a floating point exception. The program does nothing but return 0 from main which leads me to believe there is some incompatibility with the start-up code perhaps ABI? The program is compiled with gcc with the following build specs: Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr

ELF(Executable and Linkable Format)

和自甴很熟 提交于 2019-11-28 15:43:34
目录 0. 引言 1. ELF文件格式 2. ELF格式分析工具 0. 引言 0x1: ELF文件类型 ELF文件标准里把系统中采用ELF格式的文件归为以下几类 1. 可重定位文件(Relocatable File) 这类文件包含了代码和数据,可以被用来链接成可执行文件或共享目标文件,静态链接库也可以归为这一类 1) .o文件 2. 可执行文件(Executable File) 这类文件包含了可以直接执行的程序,它的代表就是ELF可执行文件,它们一般都没有扩展名 1) /bin/bash文件 3. 共享目标文件(Shared Object File) 这种文件包含了代码和数据,可以在以下两种情况下使用 1) 链接器可以使用这种文件跟其他的可重定位文件和共享目标文件链接,产生新的目标文件 2) 动态链接器可以将几个这种共享目标文件与可执行文件结合,作为进程映像的一部分来运行 共享目标文件典型的类型就是: .so文件 4. 核心转储文件(Core Dump File) 当进程意外终止时,系统可以将该进程的地址空间的内容及终止时的一些其他信息转储到核心转储文件 1) core dump 1. ELF文件格式 我们知道,对于windows中使用的PE文件结构来说,也存在一种"磁盘上PE结构"和"内存中PE结构"的概念,原因在于操作系统为了提高CPU的读写效率

What is the difference between ELF files and bin files?

梦想与她 提交于 2019-11-28 15:09:40
The final images produced by compliers contain both bin file and extended loader format ELf file ,what is the difference between the two , especially the utility of ELF file. A Bin file is a pure binary file with no memory fix-ups or relocations, more than likely it has explicit instructions to be loaded at a specific memory address. Whereas.... ELF files are Executable Linkable Format which consists of a symbol look-ups and relocatable table, that is, it can be loaded at any memory address by the kernel and automatically, all symbols used, are adjusted to the offset from that memory address

GCC __attribute__ 和 link 脚本控制 section 基地址

烂漫一生 提交于 2019-11-28 14:16:23
GCC __attribute__ 和 link 脚本控制 section 基地址 网上看的一篇文章,感谢作者,另外加上自己的一点注释。 ... ... ... ... .... .... ..... 利用 GCC 的 __attribute__ 属性的 section 选项来控制数据区的基地址。 以下例子,主要涉及到两个知识点,一个是 GNU C 扩展中的 attribute section 属性,关于这个知识点的相关信息可以参考: http://www.groad.net/bbs/read.php?tid=1035 另外一个知识点是 ld 连接器所用到的 link 脚本相关知识。 测试代码 : #include <stdio.h> int localmemory0 __attribute__ (( section ( "LOCALmem" ))) = 0 ; int localmemory1 __attribute__ (( section ( "LOCALmem" ))) = 0 ; int globalmemory __attribute__ (( section ( "GLOBALmem" ))) = 0 ; int main ( int argc , char * argv []) { localmemory0 = 0x456 ; localmemory1 =