龙瑜的博客

本文通过一个 demo 程序来理解 dlopen 的 RTLD_LOCAL flag

本文翻译了 debian11 上 man dlopen 的内容，旨在通过翻译来学习 dlopen 支持的功能。

问题描述rsyslogd: symbol lookup error: rsyslogd: undefined symbol: fjson_global_do_case_sensitive_comparison解决方法[root@localhost ~]# LD_DEBUG='symbols' /usr/sbin/rsyslogd 2>&1 |grep fjson_global_do_case_sen 3434: symbol=fjson_global_do_cas

#include<pthread.h>#include <stdio.h>#include<unistd.h>__thread int var;int data;void* worker1(void* arg){ var = data; printf("var is %d\n", var); return NULL;}int main(void){ pthread_t pid1; var = 2; data = var; p

dlsym(RTLD_NEXT, “rte_eal_init”))https://gist.github.com/apsun/1e144bf7639b22ff0097171fa0f8c6b1/*Hook main() using LD_PRELOAD, because why not?Obviously, this code is not portable. Use at your own risk.* Compile using 'gcc hax.c -o hax.

前言我最近对动态库的实现非常好奇，自己琢磨了半天没有看出什么名堂，就想着能不能找到一本讲相关内容的书籍，网上搜索了下发现确实有这样的一本书，书名为《Linux 二进制分析》。动态库的工作原理从这本书中能够找到解答，在本文中，我将使用下面这个 hello程序来验证。#include <stdio.h>int main(int argc, char* argv[]){ printf("hello world\n"); return 0;}第一个问题：printf 函数调用

前言在 could not insert module test.ko: Invalid parameters 这篇文章中，我描述过MODVERSIONS 功能对模块依赖的外部符号校验的功能。最近在搞一个项目时，需要修改 Module.symvers 中的符号 crc 值来跳过内核的符号校验过程以成功加载驱动，就按照以前的认识修改了 Module.symvers 文件内容，却发现并没有生效。经过一系列的尝试我发现之前对 Module.symvers 文件的理解很不到位，只描述了其中的一星半点。

前言在 ELF file OS ABI invalid 与 chroot 大法 这篇文章中，我描述了 libc.so ABI 的特别之处，它的 ABI 为 GNU 扩展格式而非 System V 格式。在本文中研究下它如此特别的原因。elf.h 中的相关定义系统头文件路径中，与这个 ABI 相关的宏在 /usr/include/elf.h 文件中定义，相关代码摘录如下： 138 #define EI_OSABI 7 /* OS ABI identification */ 139

本文中描述了默认链接脚本中使用的一些链接脚本关键词的功能。PROVIDE 相关命令与 . 标号PROVIDE 命令首先我们需要关注 PROVIDE 这个命令，其含义如下：在一些情况中，链接脚本需要定义一个只被引用且没有在链接时使用的任何对象文件中被定义的符号。例如，传统的链接器定义了 etext 符号。然而，ANSI C需要用户能够不遇到任何错误就能将 etext 作为一个函数的名称。PROVIDE 关键字可以被用来定义一个符号，例如 etext，相当于当它被引用且没有定义的时候提供一个默认

preinit_array 段脚本 .preinit_array : { PROVIDE_HIDDEN (__preinit_array_start = .); KEEP (*(.preinit_array)) PROVIDE_HIDDEN (__preinit_array_end = .); }preinit_array section 与 init_array section 功能类似，不过此 section 中的函数地址对应的函数在 init_array

ENTRY 标号ENTRY(_start)ENTRY 标号指定可执行程序的入口。对应这里便是 _start 函数，这个函数为 main 函数执行做了一些准备工作。需要说明的是对用户程序代码而言 main 函数是执行入口，但对整个 elf 可执行文件而言，_start 文件才是执行入口。我在 嵌入式中指定程序执行入口 中有对 ENTRY 标号与程序执行入口更具体的描述，这里就不赘述了。_start 函数从哪里来？我们在编码时并没有实现任何名为 _start 函数，那这个函数是从哪里来的呢？实

libc.so 的 elf 头部中，Magic 与大多数 so 文件、可执行文件不同。/usr/include/elf.h 138 #define EI_OSABI 7 /* OS ABI identification */ 139 #define ELFOSABI_NONE 0 /* UNIX System V ABI */ 140 #define ELFOSABI_SYSV 0 /* Alias. */ 141 #define ELFOSAB

这里有如下两个地方需要注意：ENTRY(_start)ENTRY 标号指定可执行程序的入口为 __start 函数，这个函数为 main 函数执行做了一些准备工作，对用户程序代码而言 main 函数是执行入口，但对整个 elf 可执行文件而言，__start 文件才是执行入口。__start 函数在链接时[longyu@debian-10:07:42:57] x86_64-linux-gnu $ nm -o *.o | grep _startnm: crtn.o：无符号crt1.o:0000

elf 格式研究专栏文章前几个月研究了下内核模块的加载过程，发现在这一过程中有很多针对 elf 可执行文件的操作代码，如 elf 头的校验，elf 代码段与数据段的加载与内存中重新布局等等过程，最近在研究 exec 系统调用的实现时也看到了类似的过程，诸如 load_binary、load_shlib 等函数指针的实现代码。以上两个例子足以说明 elf 格式的重要性，基于这样的情况，我开一个新的专栏，着重研究下 elf 格式文件，同时也将内核中与 elf 解析等操作相关的代码进行分析，以期清除程序的加载