我正在编写一个共享对象，它应该是 LD_PRELOAD ed 到进程中。
在那个共享对象中，我有一些初始化，比如
__attribute__((constructor)) void initFunc();
我希望在流程中的任何其他代码之前被调用。
对于只是可执行文件的进程，这可以正常工作，但如果进程本身依赖于其他一些共享对象，则这些会在我的
LD_PRELOAD 共享对象之前初始化。我尝试为链接器提供
-Wl,-z,initfirst 选项，但这似乎根本没有任何效果。当我使用 LD_DEBUG=files 运行该进程时，我仍然看到在我之前启动的应用程序。我正在运行 CentOS 5.5
最佳答案
问题是加载器只支持一个带有 -z initfirst 的共享库，而 libpthread.so(几乎所有东西都使用它)已经有了这个集合。即使您使用 LD_PRELOAD 加载库，也会首先调用 libpthread 的构造函数。
您可以通过使用 -z initfirst 修补加载程序以支持多个共享库来解决此问题。这是 ld.so 2.21 版的补丁，它保留了二进制 ABI，但从 initfirst 库中创建了一个链表，并首先使用 LD_PRELOAD 构造函数调用它们。
diff --git a/elf/dl-load.c b/elf/dl-load.c
index 6dd8550..ac3b079 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -1387,7 +1387,27 @@ cannot enable executable stack as shared object requires");
/* Remember whether this object must be initialized first. */
if (l->l_flags_1 & DF_1_INITFIRST)
- GL(dl_initfirst) = l;
+ {
+#if 0
+ struct initfirst_list *first = malloc(sizeof(*first));
+ first->which = l;
+ first->next = GL(dl_initfirst);
+ GL(dl_initfirst) = first;
+#else
+ struct initfirst_list *node = malloc(sizeof(*node));
+ node->which = l;
+ node->next = NULL;
+ struct initfirst_list *it = GL(dl_initfirst);
+ if (!it)
+ GL(dl_initfirst) = node;
+ else
+ {
+ while (it->next)
+ it = it->next;
+ it->next = node;
+ }
+#endif
+ }
/* Finally the file information. */
l->l_dev = st.st_dev;
diff --git a/elf/dl-map-segments.h b/elf/dl-map-segments.h
index baaa813..bca961c 100644
--- a/elf/dl-map-segments.h
+++ b/elf/dl-map-segments.h
@@ -55,7 +55,11 @@ _dl_map_segments (struct link_map *l, int fd,
/* Remember which part of the address space this object uses. */
l->l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
c->prot,
+#if 0
MAP_COPY|MAP_FILE,
+#else
+ MAP_COPY|MAP_FILE|MAP_32BIT,
+#endif
fd, c->mapoff);
if (__glibc_unlikely ((void *) l->l_map_start == MAP_FAILED))
return DL_MAP_SEGMENTS_ERROR_MAP_SEGMENT;
diff --git a/elf/dl-support.c b/elf/dl-support.c
index 835dcb3..9ea0c05 100644
--- a/elf/dl-support.c
+++ b/elf/dl-support.c
@@ -148,7 +148,7 @@ struct r_search_path_elem *_dl_all_dirs;
struct r_search_path_elem *_dl_init_all_dirs;
/* The object to be initialized first. */
-struct link_map *_dl_initfirst;
+struct initfirst_list *_dl_initfirst;
/* Descriptor to write debug messages to. */
int _dl_debug_fd = STDERR_FILENO;
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h
index b421931..7bb7a69 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -318,7 +318,11 @@ struct rtld_global
EXTERN unsigned long long _dl_load_adds;
/* The object to be initialized first. */
- EXTERN struct link_map *_dl_initfirst;
+ /*EXTERN struct link_map *_dl_initfirst;*/
+ EXTERN struct initfirst_list {
+ struct link_map *which;
+ struct initfirst_list *next;
+ } *_dl_initfirst;
#if HP_SMALL_TIMING_AVAIL || defined HP_TIMING_PAD
/* Start time on CPU clock. */
我想您可以尝试破解 libpthread 以不使用 -z initfirst，但这似乎是最简单的选择。我已经成功地使用它来获得一个在其他任何事情之前调用的构造函数。您只需要确保您的 LD_PRELOADed 库不使用 libc，因为这样会首先调用 libc 的构造函数，而在多线程程序中，libc 依赖于 libpthread，因此将在此之前调用 pthread 的构造函数。
这是一个例子。我用 -pthread 编译了一个 hello, world 程序(否则没有问题)。我写了一个小库，它是 LD_PRELOADed 并且不依赖于 libc。使用默认加载程序，您无法先调用 init 函数:
$ cat hello.c
#include <stdio.h>
int main() {
puts("Hello, world!");
return 0;
}
$ gcc hello.c -o hello -pthread
$ cat superearly.c
#include <unistd.h>
#include <sys/syscall.h>
long write(int fd, const void *buffer, size_t len) {
unsigned long ret;
__asm__ __volatile__("syscall" : "=a"(ret) : "a"(__NR_write), "D"(fd),
"S"(buffer), "d"(len));
return ret;
}
void hello(void) __attribute__((constructor));
void hello(void) {
write(STDOUT_FILENO, "Got in first!\n", 14);
}
$ gcc superearly.c -fPIC -shared -nostdlib -o libsuperearly.so -Wl,-z,initfirst
$ LD_DEBUG=libs LD_PRELOAD=./libsuperearly.so ./hello
19997: find library=libpthread.so.0 [0]; searching
19997: search cache=/etc/ld.so.cache
19997: trying file=/lib/x86_64-linux-gnu/libpthread.so.0
19997:
19997: find library=libc.so.6 [0]; searching
19997: search cache=/etc/ld.so.cache
19997: trying file=/lib/x86_64-linux-gnu/libc.so.6
19997:
19997:
19997: calling init: /lib/x86_64-linux-gnu/libpthread.so.0
19997:
19997:
19997: calling init: /lib/x86_64-linux-gnu/libc.so.6
19997:
19997:
19997: calling init: ./libsuperearly.so
19997:
Got in first!
19997:
19997: initialize program: ./hello
19997:
19997:
19997: transferring control: ./hello
19997:
Hello, world!
19997:
19997: calling fini: ./hello [0]
19997:
19997:
19997: calling fini: /lib/x86_64-linux-gnu/libpthread.so.0 [0]
19997:
$
但是，使用上面的补丁修补了 ld.so:
$ LD_DEBUG=libs LD_PRELOAD=./libsuperearly.so ~/libc/lib/ld-2.21.so ./hello
19986: find library=libpthread.so.0 [0]; searching
19986: search cache=/home/user/libc/etc/ld.so.cache
19986: trying file=/home/user/libc/lib/libpthread.so.0
19986:
19986: find library=libc.so.6 [0]; searching
19986: search cache=/home/user/libc/etc/ld.so.cache
19986: trying file=/home/user/libc/lib/libc.so.6
19986:
19986:
19986: calling init: ./libsuperearly.so
19986:
Got in first!
19986:
19986: calling init: /home/user/libc/lib/libpthread.so.0
19986:
19986:
19986: calling init: /home/user/libc/lib/libc.so.6
19986:
19986:
19986: initialize program: ./hello
19986:
Hello, world!
19986:
19986: calling fini: ./hello [0]
19986:
19986:
19986: calling fini: /home/user/libc/lib/libpthread.so.0 [0]
19986:
$
关于Linux:LD_PRELOAD + -z,initfirst，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/19796383/