elf | 易学教程

ELF core file format

阅读更多关于 ELF core file format

问题 Short of digging through GDB source, where can I find documentation about the format used to create core files? The ELF specification leaves the core file format open, so I guess this should be part of the GDB specifications! Sadly, I did not find any help in this regard from GNU's gdb documentation. Here's what I am trying to do: Map virtual addresses to function names in executable/libraries that comprised the running process. To do that, I would first like to figure out, from the core file

How to print the name of the symbols of ELF files like the nm?

阅读更多关于 How to print the name of the symbols of ELF files like the nm?

I know the name of the symbols are in the shstrtab. But I don't get how to catch them. Should I cast my shstrab into a Elf64_Sym so that I can use the st_name? Elf64_Shdr *shdr = (Elf64_Shdr *) (data + elf->e_shoff); Elf64_Shdr *symtab; Elf64_Shdr *shstrtab; Elf64_Shdr *strtab; char *str = (char *) (data + shdr[elf->e_shstrndx].sh_offset); for (int i = 0; i < elf->e_shnum; i++) { if (shdr[i].sh_size) { printf("%s\n", &str[shdr[i].sh_name]); if (strcmp(&str[shdr[i].sh_name], ".symtab") == 0) symtab = (Elf64_Shdr *) &shdr[i]; if (strcmp(&str[shdr[i].sh_name], ".shstrtab") == 0) shstrtab = (Elf64

Creating ELF instead of a.out

阅读更多关于 Creating ELF instead of a.out

I need to generate a simple "Hello World" ELF32 executable using gcc. I don't seem to have the gcc-elf command though. Is it possible to create ELF binaries instead of a.out without building gcc again? (I'm assuming it should be possible with some options, but am unsure how to proceed) a.out is very old, we're talking kernel version 1.2 of linux. Assuming you are operating on any remotely recent linux platform, you are generating elf executables by default. Use the file command on the output executable to verify. E.g.: $ file server server: ELF 32-bit LSB executable, Intel 80386, version 1

Core dump note section

阅读更多关于 Core dump note section

问题 Following my question about manually generating a core dump file, I decided to dive into it and get my hands dirty. I am able to build the basic core dump structure and get my dead program's memory back into the core dump within a big LOAD section. When debugging in GDB, my variables are back, no problem with that. Here comes the tricky part, how do I get GDB to retrieve information about where the program was when it crashed. I know that the note section of the core dump contains this

gcc compiled binaries w/different sizes?

阅读更多关于 gcc compiled binaries w/different sizes?

问题 If the same code is built at different times w/gcc, the resulting binary will have different contents. OK, I'm not wild about that, but that's what it is. However, I've recently run into a situation where the same code, built with the same version of gcc, is generating a binary with a different size than a prior build (by about 1900 bytes). Does anyone have any idea what may be causing either of these situations? Is this some kind of ELF issue? Are there any tools out there (other than ldd)

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 to load the data section at any particular address. If the string is stored at some address above

如何区分进程和线程ps -eLf

阅读更多关于如何区分进程和线程ps -eLf

方式使用ls /proc/pid/task/ 查看线程使用ps -eLf命令/ps aux -L/ps aux -el 使用pstree 进程和线程进程是资源分配的最小单位线程是cpu时间片分配的最小单位一个进程至少包含一个线程，即主线程 ps -eLf各字段含义 UID：用户ID PID：process id 进程id PPID: parent process id 父进程id LWP：表示这是个线程；要么是主线程(进程)，要么是线程 NLWP: num of light weight process 轻量级进程数量，即线程数量 STIME: start time 启动时间 TIME: 占用的CPU总时间 TTY：该进程是在哪个终端运行的;pts/0~255代表虚拟终端，一般是远程连接的终端;tty1~tty7 代表本地控制台终端 CMD：进程的启动命令进程状态。常见的状态有以下几种： -D：不可被唤醒的睡眠状态，通常用于 I/O 情况。 -R：该进程正在运行。 -S：该进程处于睡眠状态，可被唤醒。 -T：停止状态，可能是在后台暂停或进程处于除错状态。 -W：内存交互状态（从 2.6 内核开始无效）。 -X：死掉的进程（应该不会出现）。 -Z：僵尸进程。进程已经中止，但是部分程序还在内存当中。 -<：高优先级（以下状态在 BSD 格式中出现）。 -N：低优先级。

How does adding a private member variable break C++ ABI compatibility?

阅读更多关于 How does adding a private member variable break C++ ABI compatibility?

问题 The pimpl idiom is commonly used in order to allow changing code in dynamically linked libraries without breaking ABI compatibility and having to recompile all the code that depends on the library. Most of the explanations I see mention that adding a new private member variable changes the offsets of public and private members in the class. That makes sense to me. What I don't understand is how in practice this actually breaks the dependent libraries. I've done a lot of reading on ELF files

ldd doesn't work on dynamically linked binary

阅读更多关于 ldd doesn't work on dynamically linked binary

问题 I have a binary that uses a bunch of .so files. bash-3.00$ file foo foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.21, dynamically linked (uses shared libs), not stripped But if I run ldd on this file, its not able to pick up the .so files the binary is dependent on.' bash-3.00$ ldd foo not a dynamic executable bash-3.00$ readelf does show the list of shared libraries used by the binary.. bash-3.00$ readelf -d foo Dynamic segment at offset 0x17c810 contains

Extract global variables from a.out file

阅读更多关于 Extract global variables from a.out file

Edit (updated question) I have a simple C program: // it is not important to know what the code does you may skip the code main.c #include <bsp.h> unsigned int AppCtr; unsigned char AppFlag; int SOME_LARGE_VARIABLE; static void AppTest (void); void main (void) { AppCtr = 0; AppFlag = 0; AppTest(); } static void Foo(void){ SOME_LARGE_VARIABLE=15; } static void AppTest (void) { unsigned int i; i = 0; while (i < 200000) { i++; } BSP_Test(); SOME_LARGE_VARIABLE=3; Foo(); } bsp.c extern int SOME_LARGE_VARIABLE; extern unsigned char AppFlag; unsigned int long My_GREAT_COUNTER; void BSP_Test (void) {