2017-04-13 5 views
0

Ich möchte glibc malloc als Shared Library erstellen anstatt es als Teil von libc.so zu verwendenKann ich nur glibc malloc als gemeinsame Bibliothek erstellen?

Ich verwende keine chroot, sondern versuche direkt, es zu bauen.

Wenn ich glibc als normale Build machen, gibt er den Befehl, den malloc verwendet wird, nämlich zu bauen:

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

Wie Sie sehen können, malloc gebaut wird mit -fPIC so sollte ich in der Lage sein, um es einfach als eine gemeinsame Bibliothek zu verknüpfen.

Jedoch, wenn ich diesen Befehl ausführen 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

Ich erhalte einen Fehler relocation R_X86_64_PC32 against undefined symbol `__libc_multiple_threads' can not be used when making a shared object; recompile with -fPIC

Ich verstehe nicht, warum dieser Fehler auftaucht? klar habe ich zusammengestellt malloc.c mit -fPIC

Antwort

1

Ich verstehe nicht, warum dieser Fehler auftaucht?

Das Symbol wird von malloc.o über inline Anordnung Bezug genommen wird, so wie:

# 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:" 

Als solcher erzeugt er R_X86_64_PC32 Verlagerung (normale Anrufe an externe Routinen erzeugen R_X86_64_PLT32 Verlagerungen, wenn sie mit -fPIC kompiliert). Diese Montageform setzt voraus, dass das Symbol in demselben ELF Bild definiert wird.

Im normalen Build wird dieses Symbol als verstecktes Symbol definiert (was bedeutet es in libc.so.6 definiert ist und wird nicht von diesem ausgeführt wird) in nptl/libc_multiple_threads.c.

Da Sie nicht in libc_multiple_threads.o in Ihre libmalloc.so Verknüpfung bleibt das Symbol nicht definiert, und der Linker richtig klagt: Dieses Symbol kann von außen (falscher Verlegung dafür) nicht kommen und nicht in Ihrem libmalloc.so definierte .

Sie könnten denken, dass einfaches Verknüpfen in libc_mutiple_threads.os dies lösen würde, aber Sie werden sich irren: Ihr libmalloc.so würde sich so verhalten, als wäre Ihr Prozess single-threaded, unabhängig davon, ob es tatsächlich ist oder nicht.

TL; DR: Was Sie versuchen zu tun, wird wahrscheinlich nicht funktionieren, außer durch Zufall. Es ist sehr wahrscheinlich auf mehrere Arten gebrochen werden, von denen einige sehr subtil sein könnten.

+0

Vielen Dank. Das war eine sehr klare Erklärung. Es gibt also keine einfache Möglichkeit, ein malloc.so zu hacken. Auch aus Neugier, wie hast du den Verweis auf "__libc_multiple_threads", die du in der Antwort gepostet hast, aufgespürt? – sha

+0

@sha Sie können 'malloc.so' mit tcmalloc oder jemalloc erstellen. Aber Teile von glibc zu spalten funktioniert wahrscheinlich nicht. –

Verwandte Themen