On Thursday 10 October 2002 12:23, Marc SCHAEFER wrote:
> LD_LIBRARY_PATH sous GNU/Linux et Solaris.
En fait, je rencontre souvent des packages sous Linux qui offrent plusisurs
possibilit�s pour pr�ciser le *SHLIB_PATH � l'�x�cution. Il est vrai que l'on
ne devrait pas faire de getenv("MY_SHLIB_PATH) dans son code, mais plut�t
s'en remettre au standard (avis aux d�velopeurs !).
> dlopen(2), standard sur SYSVR4 et GNU/Linux.
C'�tait aussi le cas sous Solaris depusi longtemps et m�me HP-UX a chang� le
nom de ses fonctions :-) C'est donc bien LE standard (pardon pour le '_' dans
le nom de la fonction, �a m'a �chapp�...)
> En fait, il me semble bien que PIC signifie position-independant-code,
Absolument !
> ce qui en r�gle g�n�rale implique l'utilisation de l'adressage relatif dans
> le code assembleur g�n�r� par le compilateur, ce qui est moins efficace.
Normalement, ceci n'affecte que les symboles 'extern'. CAD, que tous les
appels de fonctions on jutse un calcul d'adresse supl�mentaire � effectuer
(ainsi que pour le return()). Il en va de m�me pour les variables globales...
mais comme tout le mode sait qu'il s'agit d'une pratique "honteuse"...
Suivant les architectures, cela affecte aussi le passage de param�tres des
fonctions.
> En th�orie une technique de correction d'adresse/mapping est possible,
> encore que cela impliquerait des tables de saut par processus. Je ne sais
> pas quel est l'�tat de la technique � ce niveau.
Le processeur HP-PA poss�de quelques registres (leur nombre d�pend de la
version d'HP-PA) permettant de stocker des 'space register value', acc�l�rant
le calcul des adresses dans ce cas. Le prix � payer est faible dans ce cas
(~4 cycles).
Par contre, le fait d'avoir toutes ses librairies en "sahred" induit un gain
de performance bien plus important qu'il n'y para�t. En effet, la r�duction
de taille des codes diminue de mani�re imortante la quantit� de code �
charger dans la m�moire. De plus, cela r�duit de mani�re drastique pa
"pression" sur la D-Cache du CPU. L'un dans l'autre, sur un serveur cette
politique est beaucoup plus favorable. Par contre dans le cas d'une seule
grosse application de calcul tournant sur une machine d�di�e, il y a une
l�g�re baisse de performances qui se situe, en g�n�ral, entre 2-5%, iI y a
bien s�r des cas plus extr�mes mais ils rel�vent plut�t de la d�monstration.
> Une alternative, notamment utilis� par le kernel, est de signer les
> prototypes des fonctions. Lorsqu'un module est ins�r�, il suffit que les
> signatures soient identiques et dans le cas g�n�ral cela suffit pour
> assurer la compatibilit� syntaxique (la compatibilit� s�mantique, ie ce
> que fait r�ellement la fonction est une autre histoire: mais l'on devrait
> bien s�r changer le nom d'une fonction si son r�le change).
J'ai d�velopp� une librairie charg�e de charger les librairies dynamiques et
de v�rifier la signature des fonctions appel�es. Ainsi je peux donner un
message claire concernant l'erreur. Ceci implique toutefois que l'on passe
par la notion "d'interface". CAD, qu'un interface d�fini la correspondance
entre l'appel de la fonction et sa d�finition. C'est une lourdeur
supl�mentaire mais le gain est ind�niable en ce qui concerne la qualit� du
code. Si cela int�resse quelqu'un, pas de probl�me, vous connaissez mon
adresse e-mail.
Daniel
PS: la librairie est plut�t HP-UX mais devrait se compiler sans autre sous
Linux, par contre les scripts de l'interface (2) sont en dtksh...(je n'ai pas
encore fait de version php) :-(
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
