elf

I've been reading the ELF specification and cannot figure out where the program entry point and _start address come from. It seems like they should have to be in a pretty consistent place, but I made a few trivial programs, and _start is always in a different place. Can anyone clarify? The _start symbol may be defined in any object file. Normally it is generated automatically (it corresponds to main in C). You can generate it yourself, for instance in an assembler source file: .globl _start _start: // assembly here When the linker has processed all object files it looks for the _start symbol

I've built a test ELF program using the LSB SDK ( note that my question is not specific to LSB ): $ /opt/lsb/bin/lsbcc tst.c $ ls -l a.out -rwxr-xr-x 1 math math 10791 2009-10-13 20:13 a.out $ file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped But I am unable to launch it ( yes, I assure you the file is in the directory... ): $ ./a.out bash: ./a.out: No such file or directory $ uname -a Linux math 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux I think there is an ELF

I'm trying to get the correct offset to the section name by accessing the sh_name member of an elf file, but it keep giving me zero, or null... I'm supposed to only use mmap() and the elf.h - no helper functions So I did: void* map_start = mmap(0, fd_stat.st_size, PROT_READ | PROT_WRITE , MAP_SHARED, fd, 0)) header = (Elf32_Ehdr *) map_start; secoff = header->e_shoff; section = (Elf32_Shdr *)(map_start + secoff); but when I do: printf("name offset = %d\n", (section->sh_name)); it keeps giving me 0... what am I doing wrong? when i do printf("name offset = %d\n", (section->sh_name)); it keeps

When the program launches (linux, elf) - is there zeros in eax , ebx , etc. or there can be anything (i'm not doing any calls or using extern libraryies)? On my machine it is really so, can I relay on such behavior when writing asm programms? This depends entirely on the ABI for each platform. Since you mention eax and ebx let's see what's the case for x86. In fs/binfmt_elf.c line #972, inside load_elf_binary() , the kernel checks if the ABI specifies any requirements for register values at program loading: /* * The ABI may specify that certain registers be set up in special * ways (on i386

I have to write a C program that prints an ELF file. I'm having trouble figuring out where the section header string table is. Let's say I have a file that gave me the following output with: readelf -h ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 17636 (bytes into file) Flags: 0x0 Size of this header: 52

I mean could a single binary file run in both Win32 and Linux i386 ? This is not possible, because the two types have conflicting formats: The initial two characters of a PE file must be 'M' 'Z' ; The initial four characters of an ELF file must be '\x7f' 'E' 'L' 'F' . Clearly, you can't create one file that satisifies both formats. In response to the comment about a polyglot binary valid as both a 16 bit COM file and a Linux ELF file, that's possible (although really a COM file is a DOS program, not Windows - and certainly not Win32). Here's one I knocked together - compile it with NASM. It

Assume main.c uses symbols from shared libs and local functions declared in main.c . Is there a nice and elegant way to print a list of all the available function names and symbols at run time? It should be possible since the data is loaded to the .code segment. Since I had the same need to retrieve all loaded symbol names at runtime, I did some research based upon R..'s answer. So here is a detailed solution for linux shared libraries in ELF format which works with my gcc 4.3.4, but hopefully also with newer versions. I mostly used the following sources to develop this solution: ELF Manpage

I was recently building a certain shared library (ELF) targeting x86-64 architecture, like this: g++ -o binary.so -shared --no-undefined ... -lfoo -lbar This failed with the following error: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC Of course, it means I need to rebuild it as position-independent code, so it's suitable for linking into a shared library. But this works perfectly well on x86 with exactly the same build arguments. So the question is, how is relocation on x86 different from x86-64 and why don't I need to