elf

The ELF Handling For Thread-Local Storage document gives assembly sequences for the various models (local exec/initial exec/general dynamic) for various architectures. But not ARM -- is there anywhere I can see such code sequences for ARM? I'm working on a compiler and want to generate code that will operate properly with the platform linkers (both program and dynamic). For clarity, let's assume an ARMv7 CPU and a pretty new kernel and glibc (say 3.13+ / 2.19+), but I'd also be interested in what has to change for older hw/sw if that's easy to explain. I don't exactly understand what you want.

参考： 《程序员自我修养》 https://blog.csdn.net/Vince_/article/details/89076338 http://www.skyfree.org/linux/references/ELF_Format.pdf 0. 简述 ElF （Executable Linkable Format 可执行可连接格式），属于 COFF （Common file format） 通用文件格式 的变种。 因为目标文件( .o) 与可执行文件内容结构相似，所以一般与可执行文件格式采取同一种存储格式。我们将其统称为ELF文件。 file filename 可以使用 file 命令查看文件类型。 常见ELF文件类型 两种不同理解ELF文件的视角 （本文选择链接视角进行解析，即第一种视角） 1. ELF中重要的section readelf -S xxx.o 查看文件中的各个段 objdump -s -d xxx.o 查看各个段的内容 ELF 文件中需要关注的一般就下图的几个段，下面对每个段进行简单解析。 ELF Header ELF文件头 readelf -h xxx.o .text 代码段 存放程序的指令。 .data 和 .rodata .data 存放已初始化的全局变量和局部静态变量。 .rodata 存放只读数据和字符串常量。（有时字符串常量在.data区

#include <stdio.h> const int str[1000] = {0}; int main(void) { printf("arr is %d\n", str[0]); return 0; } Has the following output: [-exercises/adam/stack2]:size a.out text data bss dec hex filename 5133 272 24 5429 1535 a.out Whereas: #include <stdio.h> static int str[1000] = {0}; int main(void) { printf("arr is %d\n", str[0]); return 0; } Has the following output: [-exercises/adam/stack2]:size a.out text data bss dec hex filename 1080 4292 24 5396 1514 a.out When the array is uninitialized -- it again goes to text segment for "const" and to BSS for "static". The variable is global and should

I found that when we use nested functions , GCC requires an executable stack for trampoline code . However, following code, when compiled using gcc doesn't show an executable stack. (I used execstack to verify if the stack is executable) #include <stdio.h> #include <unistd.h> int main() { int add( int a, int b) { return a + b; } return add(2, 3); } Why does this not result in a executable stack? And if it is not supposed to, then can someone give example of a code construct that does give an executable stack? If the nested function doesn't depend in its "parent"'s stack at all, then it's just

xctf pwn level3 #-*-coding:utf-8-*- from pwn import * p = process('./level3') #p = remote("111.198.29.45","36722") elf = ELF('./level3') libc = ELF('/lib/i386-linux-gnu/libc.so.6') #libc = ELF('./libc_32.so.6') write_plt = elf.plt['write'] print "write_plt: " + hex(write_plt) # print hex(elf.symbols['write']) write_got = elf.got['__libc_start_main'] print "write_got: " + hex(write_got) libc_main = libc.symbols['__libc_start_main'] print "write_libc: " + hex(libc_main) system_libc = libc.symbols['system'] print "system_libc: " + hex(system_libc) vulnfun = 0x804844B # pause() #write(1,write_got

I have a linux C program that handles request sent to a TCP socket (bound to a particular port). I want to be able to query the internal state of the C program via a request to that port, but I dont want to hard code what global variables can be queried. Thus I want the query to contain the string name of a global and the C code to look that string up in the symbol table to find its address and then send its value back over the TCP socket. Of course the symbol table must not have been stripped. So can the C program even locate its own symbol table, and is there a library interface for looking

I'm installing a modern version of gcc on solaris. I compiled gmp, mpfr and mpc, they're all 64bit. When I try to configure gcc as follows I get an error complaining that mpc,mpfr and gmp are the wrong elf class. What gives? ./../gcc-4.5.1/configure --prefix=/opt/OurAppDir/gcc --with-gmp=/opt/OurAppDir/gmp --with-mpfr=/opt/OurAppDir/mpfr --with-gnu-as --with-gnu-ld --build=sparc-sun-solaris2.10 checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking target system type... sparc-sun-solaris2.10 checking for a BSD-compatible install... ./..

THe elf file is static linked and currently the objdump's output is something like: Disassembly of section: .init: xxxxxx Disassembly of section: .plt: xxxxxx Disassembly of section: .text: xxxxxx basically what I want to achieve is "elf-file -(disassemble by objdump)-> assemble file --(re-compile)--> same functionality " I don't need the re-compiled binary has the binary content same as the original one, only same functionality is enough. After a quick search, basically the answer is no , and they argued that disassemble file lost some stuff like symbolic information or others, but I think by