elf

This question was migrated from Unix & Linux Stack Exchange because it can be answered on Stack Overflow. Migrated 6 years ago . I'm trying to access the contents of .eh_frame section of a running program from within it (specifically, the program is Linux kernel 2.6.34.8). The .eh_frame contains useful data used for exception handling and I'd like to use it internally from within kernel code. The section is already being written by gcc ( readelf -a vmlinux.o contains .eh_frame ), the problem is reading it from the code. I'm pretty sure the elf format docs say that .eh_frame is accessible

ref ：http://www.360doc.com/content/14/0509/09/17268421_376009916.shtml 一、编译器相关知识学习 GNU GCC简介： GNU GCC是一套面向嵌入式领域的交叉编译工具，支持多种编程语言、多种优化选项并且能够支持分步编译、支持多种反汇编方式、支持多种调试信息格式，目前支持X86、ARM7、StrongARM、PPC4XX、MPC8XX、MIPS R3000等多种CPU。 GNU GCC的基本功能包括：输出预处理后的C/C++源程序（展开头文件和替换宏） 输出C/C++源程序的汇编代码 输出二进制目标文件 生成静态库 生成可执行程序 转换文件格式 GCC 组成： 1. C/C++交叉编译器arm-elf-gcc arm-elf-gcc是编译的前端程序，它通过调用其他程序来实现将程序源文件编译成目标文件的功能。 编译时，它首先调用预处理程序(cpp)对输入的源程序进行处理，然后调用 cc1 将预处理后的程序编译成汇编代码，最后由arm-elf-as将汇编代码编译成目标代码。 arm-elf-gcc具有丰富的命令选项，可以控制编译的各个阶段，满足用户的各种编译需求。 2. 汇编器 arm-elf-as arm-elf-as将汇编语言程序转换为ELF (Executable and Linking Format

I need to collect some data from different .a files to one array. I do it by collecting data to one section first .c file TArElement __attribute__((section(".my.special.section"))) uwiveuve = { ... second .c file TArElement __attribute__((section(".my.special.section"))) egwegwxb = { ... etc. in ld script __my_mega_array_begin = ABSOLUTE(.); KEEP(*(.my.special.section)) __my_mega_array_end = ABSOLUTE(.); in main .c file extern TArElement *__my_mega_array_begin extern TArElement *__my_mega_array_end const t_size array_size = __my_mega_array_end - __my_mega_array_begin; So anyone can link his

I think a major design flaw in Linux is the shared object hell when it comes to distributing programs in binary instead of source code form. Here is my specific problem: I want to publish a Linux program in ELF binary form that should run on as many distributions as possible so my mandatory dependencies are as low as it gets: The only libraries required under any circumstances are libpthread, libX11, librt and libm (and glibc of course). I'm linking dynamically against these libraries when I build my program using gcc. Optionally, however, my program should also support ALSA (sound interface),

I have been reading about the relocation and symbol resolution process and I have a few questions on the same. So the whole process(of loading the exec) starts with exec(BA_OS) command. During exec(BA_OS) , the system retrieves a path name from the PT_INTERP segment and creates the initial process image from the interpreter file’s segments. That is, instead of using the original executable file’s segment images, the system composes a memory image for the interpreter. It then is the interpreter’s responsibility to receive control from the system and provide an environment for the application

I can debug some program (say /bin/ls) like this: [ks@localhost ~]$ gdb -q --args /bin/ls Reading symbols from /bin/ls...Reading symbols from /bin/ls...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install coreutils-8.22-19.fc21.x86_64 (gdb) start Temporary breakpoint 1 at 0x402990 Starting program: /usr/bin/ls [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, 0x0000000000402990 in main () (gdb) Here I can set temporary breakpoint at main and

I'm a beginner in compilers but I'm very interested in learning about how a program is structured (the binary) and how it is read and loaded in memory for execution. What ebooks/books/tutorials do you guys suggest me reading for a quick start? Compilers and executable binaries are remotely related. (the actual executable is built by the linker ld , not the compiler). On Linux systems, the linux kernel use copy-on-write and demand-paging techniques to lazily load the program pages, for ELF executables. Shared libraries may be dynamically loaded and preferably contain position independent code .

I want to compile a shared library with an .interp segment. #include <stdio.h> int foo(int argc, char** argv) { printf("Hello, world!\n"); return 0; } I'm using the following commands. gcc -c -o test.o test.c ld --dynamic-linker=blah -shared -o test.so test.o I end up without an INTERP segment, as if I never passed the --dynamic-linker=blah option. Check with readelf -l test.so . When building an executable, the linker processes the option correctly and puts an INTERP segment in the program header. How to do I make it work for shared libraries too? jacwah ld doesn't include a .interp section

if I create a shared library without a SONAME like this gcc -shared libfoo.o -o libfoo.so and link against it, how does the linker find my shared library? Is the filename libfoo.so considered as default SONAME by the linker? I think you're right. Here what ld man pages say: -soname=name When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the