De façon plus précise, si tu tiens absolument à passer des semaines (voire des mois) à coder en assembleur ce qui est nécessaire pour appeler une librarie dynamique (donc sans faire un exécutable classique linké dynamiquement) tu pourrais faire un peu ce que fait ld.so (qui est codé en C, pas en assembleur) et donc
faire les appels systèmes (et notamment stat et mmap) de la libfoo.so que tu cherches à appeler pour la projeter convenablement en mémoire (donc son segment de code exécutable mmap-é séparément du segment de données)
faire l'édition de liens dynamique (cat traiter la GOT et PLT du fichier ELF libfoo.so)
modifier en place ton code assembleur pour appeller les routines de libfoo.so
faire enfin les appels.
Tout ça est possible (c'est le boulot de ld.so), il te faut étudier la spécification de ELF et des appels systèmes Linux.
Mais tu en as pour des semaines ou des mois de travail, à refaire ld.so
Tu pourrais donc te documenter sur
ELF ,
AMD64 ELF ABI, etc. La lecture du fichier unexec.c d'Emacs (ou autre) est extremement utile.
Mais je te déconseille fortement de coder en assembleur (surtout un exécutable dynamiquement lié, comme ils le sont presque tous) un programme. Tout au plus, tu codes en assembleur une ou deux routines de bas niveau (et il vaut mieux de nos jours utiliser les builtin spécifiques de ton architecture, par exemple AMD64, dans GCC, ou l'asm dans GCC). Tu pourrais alternativement générer du code à la volée (avec llvm, libjit, lightning) avec des techniques d'optimisations adaptatives. (Albert Cohen, Gregori Fursin, tous deux à INRIA Saclay, ont publiés récemment des papiers pertinents à ce sujet). Enfin, tu pourrais (c'est plus simple) coder un compilateur pour ton langage spécialisé (en t'appuyant sur LLVM ou GCC pour la génération de code).
J'aimerais vraiment comprendre quelle mouche te pique à vouloir coder un programme tout entier en assembleur.
C'est totalement
fou de coder en assembleur de nos jours
un programme tout entier (surtout qui linke une librarie dynamique). Si la performance t'obsèdes, codes tout au plus quelques routines critiques en assembleur (routines que tu appelles depuis ton programme codé en C ou autre). Mais pas un programme entier! Et ton assembleur sera obsolète avant que tu ne l'aies terminé (coder plusieurs dizaines de milliers de ligne d'assembleur nécessaire au link dynamique te prendra plusieurs années)! En effet, les critères d'optimisation varient d'un processeur à un autre (par exemple
celui pour les vieux AMD64 est différent de celui pour les Phénom récents, ou les Core2 récents).
Expliques nous quand même quel est ce programme extraordinaire que tu codes en assembleur!
PS. Je connais un peu le sujet. Autrefois, j'avais codé l'équivalent d'un unexec sous Sparc (dans un code propriétaire qui n'a jamais servi). Et je travaille actuellement sur
GCC que je connais
un peu. Donc bon courage.
----
Basile STARYNKEVITCH
Membre de l'
APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!
Projet logiciel libre:
RefPerSys