Makefile Aufgabe 4 (jbuffer)

Bachelor Systemprogrammierung
1

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

2

Makefile Aufgabe 4 (jbuffer)
Hi,
ich denke mein Makefile ist so gut wie fertig, allerdings habe ich eine Frage:
Ist der letzte Hinweis auf dem Aufgabenblatt so gemeint, dass ich manuell vor dem Ausführen meines dynamisch gebundenen Programms die Umgebungsvariable ändern muss oder ist gemeint, dass es möglich wäre, dies im Makefile zu realisieren und dass dies auch gefordert ist?

3

Ersteres.

4

man kanns schon ins makefile reinschreiben :stuck_out_tongue_winking_eye:

16 .PHONY: test-dynamic
17 test-dynamic: jbuffer-test-dynamic
18 LD_LIBRARY_PATH=. ./jbuffer-test-dynamic

aber das war nicht gefordert

5

Das Flag -fPIC braucht man nicht wirklich für die dynamische Bibliothek, oder?
Weil, es funktioniert bei mir auch ohne, dass ich das verwende.
Und falls doch, ist es schlimm, wenn man die Object-Files grundsätzlich damit kompiliert oder muss man da zwischen der dynamischen und statischen Version differenzieren?

6

Noch etwas:
Wenn ich mein Makefile daheim benutze funktioniert es einwandfrei, aber auf den Unirechnern (ueber ssh in dem Fall) haengt es an folgendem Problem:
gcc: error: unrecognized command line option ‘-WL,-soname,libjbuffer-dynamic.so.1’
Edit: Habe den Teil einfach rausgeschnitten und es funktioniert trotzdem. Ist also weiter kein Problem, schaetz ich…

7

Doch, das Flag brauchst du. Es funktioniert zwar interessanterweise auf x86 (bin mir gerade nicht sicher warum), aber auf x64 und auf anderen Architekturen funktioniert das nicht:

$ uname -m
x86_64
$ cc -c -D_XOPEN_SOURCE=700 -std=c99 -pedantic -Wall -Werror -pthread sem.c
$ cc -c -D_XOPEN_SOURCE=700 -std=c99 -pedantic -Wall -Werror -pthread jbuffer.c
$ cc -o libjbuffer-dynamic.so -shared -std=c99 -pedantic -Wall -Werror -pthread -L. sem.o jbuffer.o
/usr/bin/ld: sem.o: relocation R_X86_64_PC32 against undefined symbol `malloc@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC

Ja. Du musst zwei Versionen der .o-Dateien erstellen. Einmal mit [m]-fPIC[/m] und einmal ohne.

Wieso wolltest du diese Option verwenden? (Btw. es müsste ein kleines l sein.)

8

So weit ich weiß, können dynamische Bibliotheken unter x86_32 beim Laden reloziert werden - das heißt, sie können an eine beliebige Stelle im virtuellen Speicher geschoben werden und alle absoluten Adressbezüge im Code werden vom Lader entsprechend umgerechnet und „gepatcht“.

Das hat natürlich zwei Nachteile:

  • Das Laden dauert ein Stückchen (vermutlich nicht wirklich signifikant) länger.
  • Jeder Prozess, der diese Bibliothek benutzt, braucht seine eigene, relozierte Kopie der Bibliothek im Hauptspeicher. Die Bibliothek kann also nicht einmalig in den Hauptspeicher geladen und dann einfach in die Adressräume aller Prozesse, die sie benutzen, eingeblendet werden.
1 Like
9

Vielen Dank für die Erklärung.

Habs mir nochmal angeschaut, man sieht den Unterschied deutlich in [m]readelf[/m]:

$ readelf -r lib-without-fpic.so
Relocation section '.rel.dyn' at offset 0x674 contains 49 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000b57  00000008 R_386_RELATIVE   
00000b5f  00000008 R_386_RELATIVE   
00001000  00000008 R_386_RELATIVE   
00001004  00000008 R_386_RELATIVE   
0000112c  00000008 R_386_RELATIVE   
0000099f  00000a02 R_386_PC32        00000000   malloc
00000b6d  00000a02 R_386_PC32        00000000   malloc
00000b8c  00000a02 R_386_PC32        00000000   malloc
[...]
00000ca8  00001d02 R_386_PC32        00000a26   semDestroy
00000ce8  00001a02 R_386_PC32        00000a91   P
00000d85  00001a02 R_386_PC32        00000a91   P
00000d61  00001b02 R_386_PC32        00000aee   V
00000de9  00001b02 R_386_PC32        00000aee   V
00001104  00000306 R_386_GLOB_DAT    00000000   _ITM_deregisterTMClone
00001108  00000906 R_386_GLOB_DAT    00000000   __cxa_finalize
0000110c  00000b06 R_386_GLOB_DAT    00000000   __gmon_start__
00001110  00000f06 R_386_GLOB_DAT    00000000   _Jv_RegisterClasses
00001114  00001006 R_386_GLOB_DAT    00000000   _ITM_registerTMCloneTa

Relocation section '.rel.plt' at offset 0x7fc contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00001124  00000907 R_386_JUMP_SLOT   00000000   __cxa_finalize
00001128  00000b07 R_386_JUMP_SLOT   00000000   __gmon_start__
$ readelf -r lib-with-fpic.so
Relocation section '.rel.dyn' at offset 0x674 contains 8 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00002070  00000008 R_386_RELATIVE   
00002074  00000008 R_386_RELATIVE   
000021d0  00000008 R_386_RELATIVE   
0000216c  00000306 R_386_GLOB_DAT    00000000   _ITM_deregisterTMClone
00002170  00000906 R_386_GLOB_DAT    00000000   __cxa_finalize
00002174  00000b06 R_386_GLOB_DAT    00000000   __gmon_start__
00002178  00000f06 R_386_GLOB_DAT    00000000   _Jv_RegisterClasses
0000217c  00001006 R_386_GLOB_DAT    00000000   _ITM_registerTMCloneTa

Relocation section '.rel.plt' at offset 0x6b4 contains 17 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000218c  00000107 R_386_JUMP_SLOT   00000000   pthread_mutex_unlock
00002190  00000207 R_386_JUMP_SLOT   00000000   pthread_mutex_destroy
00002194  00000407 R_386_JUMP_SLOT   00000000   pthread_cond_broadcast
00002198  00001a07 R_386_JUMP_SLOT   00000acb   P
0000219c  00001b07 R_386_JUMP_SLOT   00000b38   V
[...]
000021cc  00001407 R_386_JUMP_SLOT   000009b0   semCreate

Die Bibliothek ohne [m]-fPIC[/m] hat deutlich mehr Relocations.

Details zu den Relocations findet man in der ELF-ABI für i386: http://www.sco.com/developers/devspecs/abi386-4.pdf

2 Likes