【问题标题】:Can I build only glibc malloc as a shared library?我可以只构建 glibc malloc 作为共享库吗?
【发布时间】:2017-04-13 13:20:53
【问题描述】:

我想将 glibc malloc 构建为共享库,而不是将其作为 libc.so 的一部分

我没有使用任何 chroot,而是直接尝试构建它。

当我将 glibc 作为普通构建时,它会输出用于构建 malloc 的命令:

gcc malloc.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes -fPIC -DMORECORE_CLEARS=2 -I../include -I/home/sharath.g/glibc-2.20/build/malloc -I/home/sharath.g/glibc-2.20/build -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -o /home/sharath.g/glibc-2.20/build/malloc/malloc.o -MD -MP -MF /home/sharath.g/glibc-2.20/build/malloc/malloc.os.dt -MT /home/sharath.g/glibc-2.20/build/malloc/malloc.os

如您所见,malloc 是使用 -fPIC 构建的,因此我应该能够简单地将其链接为共享库。

但是当我运行这个命令时 gcc -shared -Wl,-soname,libmalloc.so -shared -lpthread -lm -lrt -o /home/sharath.g/glibc-2.20/build/malloc/libmalloc.so /home/sharath.g/glibc-2.20/build/malloc/malloc.o

我收到一个错误 relocation R_X86_64_PC32 against undefined symbol `__libc_multiple_threads' can not be used when making a shared object; recompile with -fPIC

我不明白为什么会出现这个错误?显然我已经用 -fPIC 编译了 malloc.c

【问题讨论】:

    标签: malloc linker-errors glibc relocation fpic


    【解决方案1】:

    我不明白为什么会出现这个错误?

    malloc.o 通过内联汇编引用符号,如下所示:

    # 69 "../sysdeps/unix/sysv/linux/x86_64/lowlevellock.h"
    #define __lll_trylock_asm "cmpl $0, __libc_multiple_threads(%%rip)\n\t" "je 0f\n\t" "lock; cmpxchgl %2, %1\n\t" "jmp 1f\n\t" "0:\tcmpxchgl %2, %1\n\t" "1:"
    

    因此,它会生成R_X86_64_PC32 重定位(在使用-fPIC 编译时,对外部例程的正常调用会生成R_X86_64_PLT32 重定位)。这种组装形式假定符号将在同一个ELF 图像中定义。

    在正常构建中,此符号在nptl/libc_multiple_threads.c 中被定义为隐藏符号(意味着它在libc.so.6 中定义并且不会从中导出)。

    由于您没有libc_multiple_threads.o 链接到您的libmalloc.so,因此该符号仍未定义,并且链接器正确地抱怨:此符号不能来自外部(错误的重定位)并且未在您的 libmalloc.so 中定义。

    您可能认为简单地在libc_mutiple_threads.os 中进行链接就可以解决这个问题,但您错了:您的libmalloc.so 将表现得好像您的进程是单线程的,不管它是否真的是单线程的。

    TL;DR:除非意外,否则您尝试做的事情不太可能奏效。它非常可能以多种方式被破坏,其中一些可能非常微妙。

    【讨论】:

    • 谢谢。这是一个非常明确的解释。所以没有简单的方法来破解 malloc.so 吗?另外出于好奇,您是如何追踪您在答案中发布的对__libc_multiple_threads 的引用?
    • @sha 你当然可以使用 tcmalloc 或 jemalloc 构建malloc.so。但是拆分 glibc 的一部分不太可能奏效。
    猜你喜欢
    • 1970-01-01
    • 2012-02-07
    • 2011-01-09
    • 1970-01-01
    • 1970-01-01
    • 2011-08-27
    • 2015-10-03
    • 2011-02-23
    • 2019-08-26
    相关资源
    最近更新 更多