elf | 易学教程

What exactly does `-rdynamic` do and when exactly is it needed?

阅读更多关于 What exactly does `-rdynamic` do and when exactly is it needed?

What exactly does -rdynamic (or --export-dynamic at the linker level) do and how does it relate to symbol visibility as defined by the -fvisibility* flags or visibility pragma s and __attribute__ s? For --export-dynamic , ld(1) mentions: ... If you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself. ... I'm not sure I completely understand this. Could you please provide an example that doesn't work without -rdynamic but does

How can gcc/clang assume a string constant's address is 32-bit?

阅读更多关于 How can gcc/clang assume a string constant's address is 32-bit?

问题 If I compile this program: #include <stdio.h> int main(int argc, char** argv) { printf("hello world!\n"); return 0; } for x86-64, the asm output uses movl $.LC0, %edi / call puts . (See full asm output / compile options on godbolt.) My question is: How can GCC know that the the string's address can fit in a 32bit immediate operand? Why doesn't it need to use movabs $.LC0, %rdi (i.e. a mov r64, imm64 , not a zero or sign-extended imm32 ). AFAIK, there's nothing saying the loader has to decide

【转】gdb的调试与使用

阅读更多关于【转】gdb的调试与使用

转载自： https://www.jianshu.com/p/7a06b0bda2d8 gdb的调试与使用这篇应该是我见过的总结最详细的gdb调试指南了，这位博主是个很强的人，他的博客对萌新比较友好，我始终认为那种自己厉害又能把自己所学完美表达出来的人是最强的 1. 调试的快捷键 peda带有的功能，直接输入命令，其就会给予提示（如果不是这样，基本上也是该命令就可以不带参数）。这儿就不多做介绍 1.1 基础的调试快捷键 s step，si步入 n 执行下一条指令 ni步入 b 在某处下断点，可以用 b * adrress b function_name info b 查看断点信息 delete 1删除第一个断点 c 继续 r 执行 disas addr 查看addr处前后的反汇编代码，也可以是函数名字 1.2 显示数据 p 系列 p system/main 显示某个函数地址 p $esp 显示寄存器 p/x p/a p/b p/s。。。 p 0xff - 0xea 计算器 print &VarName 查看变量地址 p * 0xffffebac 查看某个地址处的值 x系列 x/xw addr 显示某个地址处开始的16进制内容，如果有符号表会加载符号表 x/x $esp 查看esp寄存器中的值 x/s addr 查看addr处的字符串 x/b addr 查看addr处的字符 x/i

.bss vs COMMON: what goes where?

阅读更多关于 .bss vs COMMON: what goes where?

From my book: .bss: Uninitialized global C variables COMMON: Uninitalized data objects that are not yet allocated I have to say, I don't quite see a clear distinction. I don't even quite understand what an uninitizalied, non-allocated data object is...seems like nothing. I've used GNU's readelf tool to try to take a look at some simple C code, but can't find a single COMMON symbol. I've read things like FORTRAN's COMMON type is an example of a COMMON symbol - but I don't know FORTRAN Can someone possibly distinguish the two for me? If at all possible, hopefully with a C example? Greatly

Linux的ELF文件

阅读更多关于 Linux的ELF文件

一、文件头： sizeof(Elf32_Ehdr)=52 e_type：类型---可重定位文件.o、可执行文件、共享目标文件.so e_ehsize：文件头大小---52 e_machine： CPU平台属性，如Intel_x86； e_entry：入口虚拟地址，但是可重定位文件没有； e_shoff：段表偏移量，即在ELF文件的位置；下面两个11*40=440表达段表长度 e_shnum：段表描述符数量，即段表中段的个数：11 e_shentsize：段表描述符大小，sizeof(Elf32_Shdr)=40 e_shstrndx：段表字符串表所在的段在段表中的下标；二、段表： sizeof(Elf32_Shdr)=40 sh_name：段名，如.test/.data/.bss/.rodata/.comment, .rel.text/.rel.data, .symtab, .strtab/.shstrtab, sh_type：类型---程序段、重定位表、符号表、字符串表 sh_flags：标志位---可写、可执行、分配空间 sh_addr：加载后在地址空间中的虚拟地址 sh_offset：段偏移量，即该段该文件中的地址！！！！！！！！！！！！！！！！！ sh_size：段大小 sh_link：符号表的下标 sh_info：作用于哪个段？三

x86_64: Is it possible to “in-line substitute” PLT/GOT references?

阅读更多关于 x86_64: Is it possible to “in-line substitute” PLT/GOT references?

问题 I'm not sure what a good subject line for this question is, but here we go ... In order to force code locality / compactness for a critical section of code, I'm looking for a way to call a function in an external (dynamically-loaded) library through a "jump slot" (an ELF R_X86_64_JUMP_SLOT relocation) directly at the call site - what the linker ordinarily puts into PLT / GOT, but have these inlined right at the call site. If I emulate the call like: #include <stdio.h> int main(int argc, char

virtual and physical addresses of sections in elf files

阅读更多关于 virtual and physical addresses of sections in elf files

问题 How does objdump compute the physical address (LMA) of elf sections? As far as I can tell, elf section headers only contain the virtual address (VMA) of sections [1]. Usually, VMA and LMA are the same. But for initialized data sections (.data), the VMA is the RAM location of the variables and LMA is the ROM location where the initial values are located. Crt0 is responsible for copying the initial values into RAM before main() is called. For example: $ objdump -h my.elf Sections: Idx Name Size

Why does the PLT exist in addition to the GOT, instead of just using the GOT?

阅读更多关于 Why does the PLT exist in addition to the GOT, instead of just using the GOT?

I understand that in a typical ELF binary, functions get called through the Procedure Linkage Table (PLT). The PLT entry for a function usually contains a jump to a Global Offset Table (GOT) entry. This entry will first reference some code to load the actual function address into the GOT, and contain the actual function address after the first call (lazy binding). To be precise, before lazy binding the GOT entry points back into the PLT, to the instructions following the jump into the GOT. These instructions will usually jump to the head of the PLT, from where some binding routine gets called

How do you get the start and end addresses of a custom ELF section?

阅读更多关于 How do you get the start and end addresses of a custom ELF section?

I'm working in C on Linux. I've seen the usage of of the gcc __section__ attribute (especially in the Linux kernel) to collect data (usually function pointers) into custom ELF sections. How is the "stuff" that gets put in those custom sections retrieved and used? mgalgs As long as the section name results in a valid C variable name, gcc ( ld , rather) generates two magic variables: __start_SECTION and __stop_SECTION . Those can be used to retrieve the start and end addresses of a section, like so: /** * Assuming you've tagged some stuff earlier with: * __attribute((__section__("my_custom

Why Linux/gnu linker chose address 0x400000?

阅读更多关于 Why Linux/gnu linker chose address 0x400000?

I'm experimenting with ELF executables and the gnu toolchain on Linux x86_64: I've linked and stripped (by hand) a "Hello World" test.s: .global _start .text _start: mov $1, %rax ... into a 267 byte ELF64 executable... 0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ 0000010: 0200 3e00 0100 0000 d400 4000 0000 0000 ..>.......@..... 0000020: 4000 0000 0000 0000 0000 0000 0000 0000 @............... 0000030: 0000 0000 4000 3800 0100 4000 0000 0000 ....@.8...@..... 0000040: 0100 0000 0500 0000 0000 0000 0000 0000 ................ 0000050: 0000 4000 0000 0000 0000 4000 0000 0000 ..

订阅 elf