2017-04-13 75 views
0

我想构建glibc malloc作为共享库,而不是它的一部分libc.so我可以只将glibc malloc构建为共享库吗?

我没有使用任何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

我不明白为什么这个错误显示出来?显然我已经编译malloc.c与-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:你试图做的事不太可能奏效,除非意外。这是非常可能会以多种方式打破,其中一些可能是非常微妙的。

+0

谢谢。这是一个非常明确的解释。所以有没有简单的方法来破解一个malloc.so?同样为了好奇,你是如何追踪你在答案中发布的对__libc_multiple_threads的引用? – sha

+0

@sha您当然可以使用tcmalloc或jemalloc来构建'malloc.so'。但分开glibc的一部分是不可能的。 –