En gros, on évite de faire de l'assembleur.


Si tu y tiens vraiment, tu peux mettre un peu d'assembleur dans du code C avalé par GCC. C'est le GCC inline assembly.

Attention, le résultat doit être du code PIC (position independent code).

Pourrais tu expliquer en détail pourquoi tu veux générer un .so en assembleur?

Si tu génères dynamiquement du code, considères plutôt llvm


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 22 November 2008 00:42:10

En fait, je cherche à appeler un fichier .so à partir de mon programme principal en assembleur. Cependant, je en sais pas comment appeler la fonction truc du fichier 'machin.so' en assembleur.

Le fichier .so me permettrait d'eviter de retaper systématiquement les memes fonctions dans mon programme principal. Ce fichier contenant des variables globales, je dois le mettre en fichier critique.

Poste le Thursday 27 November 2008 08:33:01

Citation
Caillou
En fait, je cherche à appeler un fichier .so à partir de mon programme principal en assembleur.

Quel est donc ce programme mystérieux que tu codes en assembleur?

En 2008, il n'y a pas de raisons de coder un programme en assembleur, et il y a de bonnes raisons pour ne pas le faire (en résumé, la machine virtuelle x86 est une abstraction eloignée de ce qui se passe dans le silicium).

Tu peux toujours réinventer la roue et ré-implementer ld.so (ou libdl.so cad dlopen) avec mmap.

Mais de mon point de vue, tu fais fausse route en codant un programme tout entier en assembleur de nos jours.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Thursday 27 November 2008 17:10:54

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

Poste le Thursday 27 November 2008 21:42:41

Pour compléter un peu ce qui a été dit, je suis tombé sur ce lien assez intéressant sr l'optimisation : [dl.fefe.de]

[catwell.info]

Poste le Monday 1 December 2008 02:42:55