dlsym ()

[bakunin]

Hi!

In der Manpage zu dlsym () steht Folgendes:

"dlsym takes a "handle" of a dynamic library returned by dlopen and the
null terminated symbol name, <b>returning the address where that symbol
is loaded</b>. If the symbol is not found, dlsym returns NULL; however,
the correct way to test for an error from dlsym is to save the result of
dlerror into a variable, and then check if saved value is not NULL.
This is because <b>the value of the symbol could actually be NULL</b>.
It is also necessary to save the results of dlerror into a variable
because if dlerror is called again, it will return NULL."

Die beiden Ausschnitte, die ich hier hervorgehoben habe, scheinen sich
zu widersprechen: Ich weiß zwar nicht, was mit "value of the symbol"
wirklich gemeint sein soll, doch ich weiß, dass per Definition NULL
keine gültige Adresse ist, und daher dort kein Symbol sein kann (wenn
doch eines dort wäre, hätte das wohl fatale Folgen, da eben ein
späterer Vergleich der Adresse mit NULL typischerweise dazu führen
würde, dass das Programm abgebrochen wird).

Liege ich hier richtig?

Dass diese Manpage generell ziemlich schlampig zusammengeschustert wurde
zeigte auch das Codebeispiel. Hier auf woody ist es zwar inzwischen
korrigiert, aber unter potato enthielt die Manpage die Zeile:

fprintf (stderr, "%s\<!--no-->n0, error);

Allerdings verleiht das natürlich dem Begriff der "nullterminierten
Strings" eine ganz neue Bedeutung.

Cheers,
GNU/Wolfgang

[Jochen]

Disclaimer: Ich habe in diesem Bereich (Laden von dynamischen Libraries zur Laufzeit) noch nie etwas programmiert. Aber ich kann man-pages lesen. <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

dlopen() bekommt ausser dem Namen der Bibliothek auch noch ein int als Flag-Variable mit. Eines der möglichen Flags ist RTLD_LAZY. Dieses weist den Loader an, dass unresolved symbols erst aufzulösen sind, wenn Code der Library ausgeführt wird. Das interpretiere ich so, dass weitere Bibliotheken, von der die gerade geladene Bibliothek abhängig ist, erst geladen werden, wenn Funktionen aus diesen Bibliotheken aufgerufen werden.

Sollte nun die von Hand geladene Bibliothek eine der Funktionen einer abhängigen Bibliothek exportieren, wäre das Symbol bekannt, aber noch kein Code dahinter, da die Bibliothek dazu noch nicht geladen wurde.

Wäre das ein erster Ansatz, oder habe ich mich in meiner Ignoranz in eine vollkommen falsche Richtung verrannt?

Eine andere Idee wäre vielleicht, dass dlsym() unter Solaris aud irgendwelchen Gründen NULL für ein Symbol zurückliefern kann, dass unter Linuzx aber nicht passiert und rein aus Portabilitätsgründen das Interface gleich gehalten wurde. Aber das sind alles nur Vermutungen.

Vielleicht hat es Dir ja einen Anstoss gegeben.

Jochen

[Jochen]

Und wie es der Teufel will, stolpere ich zufällig (Echt! Ich schwöre!) über das Program-Library-HOWTO <a href="http://www.tldp.org/HOWTO/Program-Library-HOWTO/" target="_blank"><!--auto-->http://www.tldp.org/HOWTO/Program-Libra ... <!--auto--> :<blockquote><hr>dlsym() will return a NULL result if the symbol wasn't found. If you know that the symbol could never have the value of NULL or zero, that may be fine, but there's a potential ambiguity otherwise: if you got a NULL, does that mean there is no such symbol, or that NULL is the value of the symbol? The standard solution is to call dlerror() first (to clear any error condition that may have existed), then call dlsym() to request a symbol, then call dlerror() again to see if an error occurred.<hr></blockquote>In meiner Unwissenheit ging ich davon aus, das ein solches Symbol immer eine Adresse einer Funktion in der Library ist, aber das muss wohl nicht so sein.

Jochen

[bakunin]

Hi!

Ok, dann wäre die Behauptung in der Manpage, dass die Adresse eines
Symbols geliegert wird, falsch. Übrigens bin ich auf
<a href="http://www.opengroup.org/onlinepubs/007 ... lopen.html" target="_blank"><!--auto-->http://www.opengroup.org/onlinepubs/007 ... <!--auto-->
gestoßen und da dies ein Standard ist und dort eine derartige
Möglichkeit (die in meinen Augen eher auf eine fehlerhafte Library
zurückzuführen wäre) nicht genannt wird, werde ich das mal ignorieren
und annehmen, dass NULL für einen Fehler steht, wie es der Standard
angibt.

Cheers,
GNU/Wolfgang

[Udo M.]

Von welchem Standard schreibt Wolfgang hier?

> zurückzuführen wäre) nicht genannt wird, werde ich das mal ignorieren
> und annehmen, dass NULL für einen Fehler steht, wie es der Standard
> angibt.

Wenn ein Symbol keinen Wert enthält, bekommem wir NULL, das ist doch völlig korrekt.
Ob es denn überhaupt existiert sagt uns dlerror, dasz wir NULL auch im evtl. Fehlerfall erhalten ist das, was der Standard fordert, aber doch nur Makulatur, eine kleine Hilfe:
Wenn wir sicher sind, es muß einen Wert enthalten, weil es sich z.B um die Adresse einer Funktion handelt, die in dem DSO einfach drin ist, dann dürfen wir den Wert "Funktionsadresse==NULL" als Fehler werten, ohne dlerror zu befragen (Manpage) ...
Der Standard verbietet doch nicht, NULL auch im Erfolgsfall (Symbol gefunden) zurück zu liefern. Wenn bei der Initialisierung etwa einige Werte in einem System nicht ausgemacht werden können, ist es doch korrekt, die zugehörigen Symbole mit NULL zu belegen, trotzdem existieren sie.

Ich hoffe, nicht noch mehr Verwirrung zu stiften.

Udo

[bakunin]

Hi!

Ok, im IRC hat man mir geholfen, meine Verwirrung zu beseitigen. Die
Antwort ist, dass bei einem "weak symbol" man in der Tat NULL als Wert
erhalten kann, Näheres würde man im ELF-Standard finden.

Cheers,
GNU/Wolfgang