Re: syscalls mittels ld -wrap abfangen

Thomas Maier-Komor <thomas@xxxxxxxxxxxxxx> writes:
Rainer Weikusat wrote:
Thomas Maier-Komor <thomas@xxxxxxxxxxxxxx> writes:
[...]

Warum dynamisch linken und nicht statisch? Es gibt auf PCs keinen Grund
mehr überhaupt noch statisch zu linken, denn die einzigen Vorteile die
man dadurch bekommt, sind marginal schnellere Startzeiten und
vernachlässigbare Einsparungen beim Speicherbedarf.

Das ist nicht ganz richtig. Bei einer dynamisch zu einem binary
dazugelinkten Bibliothek geht jeder Aufruf einer Routine aus dieser
Bibliothek zu einem bestimmten Ort in der procedure linkage table
(PLT), die die aufzurufende Routine indirekt ueber ihre in der global
offset table gespeicherte Adresse aufruft, dh jeder solche Aufruf ist
de facto ein indirekter Aufruf (ueber function pointer).

[...]

Ja, stimmt. Es muss aber nicht so sein. Ein neuerer ld.so könnte es
anders machen.

Aussagen im Irrealis sind immer ein wenig zweckfrei. Der Solaris
Linker and Libraries Guide' meint dazu:

[...]

If a shared object is built from position-dependent code, the
text segment can require modification at runtime. This
modification allows relocatable references to be assigned to
the location that the object has been loaded. The relocation
of the text segment requires the segment to be remapped as
writable. This modification requires a swap space reservation,
and results in a private copy of the text segment for the
process. The text segment is no longer sharable between
multiple processes. Position-dependent code typically requires
more runtime relocations than the corresponding
position-independent code. Overall, the overhead of processing
text relocations can cause serious performance degradation.

When a shared object is built from position-independent code,
relocatable references are generated as indirections through
data in the shared object's data segment. The code within the
text segment requires no modification.
(UR:<http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl1r?a=view#chapter4-29405>)

Und das Programm möchte ich sehen, bei dem dieses Verfahren zu einem
_messbaren_ und _nennenswerten_ Geschwindigkeitsverlust führt.

Hierzu muesste man erst mal ein Verfahren definieren, mit dessen Hilfe
man den overhead dieser Vorgehensweise in einem 'real world program'
ueberhaupt messen kann und ich bezweifle, dass dies moeglich ist, ohne
das Verhalten dieses Programms selber soweit zu veraendern, dass die
Resultate nichts mehr aussagen. Daraus, dass man etwas nicht sinnvoll
messen kann, folgt aber nicht, dass es nicht existiert und einen
realen Einfluss hat. Der 'nennenswerte Verlust' fuehrt auch in die
Irre: Eine ausreichend grosse Summe einzeln nicht nennenswerter
'Verluste' langt aus, um ein Regiment vollstaendig aufzureiben, obwohl
zu jedem Beobachtungszeitpunkt vielleicht nur ein 1/3000 der
Sollstaerke das Zeitliche gesegnet hatte.

Aber ich wollte eigentlich gar nicht etwas gegen dynamisches Linken
sagen, sondern nur darauf hinweisen, dass das (wie alles) auch nicht
umsonst ist. Man gewinnt verschiedene Vorteile (die Du genannt
hattest), bezahlt aber dafuer den Preis aufwendigerer
Kontrolltransfers.

Je nachdem, was man vorhat, kann man Vorteile oder Nachteile fuer
gewichtiger halten, aber um das zu koennen, muss man ueberhaupt erst
mal von ihnen wissen.

Außerdem muss das Programm so gelinkt sein, dass nur die notwendigen
Symbole ins Binary übernommen werden und nicht die ganze Bibliothek (das
macht der GNU ld nicht automatisch!).

Aber ganz sicher doch: Es werden alle members das statischen Archivs
eingebunden, aus denen Code oder Daten mittels der diesen zugeordneten
Symbolen referenziert wurden. Das ist auch wenigstens schon 'seit
ewigen Zeiten' so (mit 'seit ewigen Zeiten' ::= 'wenigstens seit 1995'
als ich das in der Dokumentation zu meinem ersten Linux gelesen habe
[RH2.0]).

Dann kannst Du mir sicher erklären was ich hier falsch gemacht habe:

[...]

thomas@smaug:~$ gcc -static h.o
thomas@smaug:~$ size a.out
text data bss dec hex filename
412816 3752 3220 419788 667cc a.out
thomas@smaug:~$ nm a.out | wc -l
1376
thomas@smaug:~$ ls -l a.out
-rwxr-xr-x 1 thomas thomas 4607673 2006-04-22 22:14 a.out*

Nichts. Nur die Schlussfolgerung ist nicht ganz korrekt: Das ist keine
Folge fehlender features im Linker, sondern eine der Struktur der Gnu
C-Library, die eben nennenswerte Teile von sich selber auch selber
benoetigt (Uli D. ist 'by design' eigenlich C++-Programmierer ...)
.

Relevant Pages

  • Re: welche werkzeuge zum programmieren und/oder welche IDE ?
    ... Das ist prinzipiell bloss ein Allgemeinplatz ('der Vorteil einer ... Bibliothek fuer spezielle Zwecke einsetzen. ... kann in C++ sehr viel Code schreiben, wo am Ende nur eine Assembler- ...
    (de.comp.os.unix.programming)
  • Re: OpenOffice
    ... Ich habe nie davon geschrieben, dass der Autor einer Bibliothek sich etwas verbaut, wenn er seinen eigenen Code unter eine bestimmte Lizenz stellt. ... der GPL steht. ... des Codes auch andere Lizenzen *anbietet*. ...
    (de.comp.lang.delphi.misc)
  • Re: welche werkzeuge zum programmieren und/oder welche IDE ?
    ... Bibliothek ist, ... Der von jemandem anders geschriebene Code, ... anstelle einer Kopierschleife fuer ints' (bei der die aligmnent-Tricks ... Wer das richtig macht, prüft mal eben ...
    (de.comp.os.unix.programming)
  • Re: autoconf considered a pure m4 lifesupport
    ... Verschiendene autoconf-Makros, haben ein zusaetzliches Argument, ... 'Der Nutzer' sollte den Code ja auch nicht portieren und autoconf wird ... nichts anderes als einen optimierenden Compiler zu bauen. ... die ich nicht habe => muss auch in configure den Test auf die Bibliothek ...
    (de.comp.os.unix.programming)