Bonjour
J'espère que tu peux lire en anglais les références que je donne (j'ai
déjà répondu récemment en anglais sur des forums à des questions très
proches des tiennes)
On 29/03/17 14:54, Philippe Deleval wrote:
Bonjour à tous
j'ai changé de machine depuis l'été 2016, j'en ai profité pour passer
de whezzie à jessie, mais j'aurais aimé rester en 32 bits (ce qui
m'aurait simplifié le travail en programmation) et j'ai été de fait
contraint de passer à 64 bits. Ma machine, de "marque" gigabyte, vient
de anyware (distributeur de lenovo) qui se trouve à un bon quart
d'heure à pieds de chez moi (Conflans Sainte Honorine). J'ai sur cette
machine une jessie avec noyau 3.16.0-4-amd64.
A mon avis passer en 64 bits est un avantage pour écrire un compilateur,
pas un inconvénient. En particulier grâce aux plus nombreux registres et
à l'ABI mieux foutue. Il faut évidemment lire
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r252.pdf et
voir http://stackoverflow.com/q/18133812/841108
J'ai deux gros problèmes de programmation en assembleur. je n'ai pas
la prétention d'affirmer qu'il faut tout écrire en assembleur, mais je
compte bien écrire des programmes qui le font pour moi, en bref des
compilateurs. Je n'ai pas envie de passer par gcc, s'il faut
l'expliquer, je trollerai ce vendredi. Je commence par mon deuxième
problème, qui m'est apparu en essayant d'explorer le premier!
C'est du code libre ton compilateur? Où est le code source? Même si rien
ne marche, ça vaut mieux de publier (dès maintenant) le code sous une
license libre (sur github ou ailleurs). J'aime écrire des compilateurs,
mais je voudrais comprendre ta motivation : est-ce d'apprendre à
optimiser, ou bien d'inventer un language de programmation chouette? (ta
vie est trop courte pour bien faire les deux à la fois). Si tu as lu
https://mitpress.mit.edu/sicp/ et
https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools
(deux lectures indispensables quand on s'intéresse à la compilation) il
faut aussi lire Principes d'implantation de Scheme et Lisp (en français,
passionnant à lire, mais parfois touffu) de C.Queinnec
http://paracamplus.com/spip/?page=livre=978-2-916466-03-3 et je
conseille aussi -en anglais- Programming Language Pragmatics
https://www.cs.rochester.edu/~scott/pragmatics/
(je connais la compilation, je suis l'architecte et le développeur
principal de GCC MELT, voir http://gcc-melt.org/ pour les détails; et
donc je connais un peu les internes de GCC)
Par ailleurs, si tu veux faire un compilateur, tu pourrais générer du
code C ; voir
https://www.quora.com/Are-there-any-disadvantages-of-using-C-as-the-intermediate-language-in-compilation-process/answer/Basile-Starynkevitch
& http://softwareengineering.stackexchange.com/a/257873/40065
ou tu pourrais envisager d'utiliser libgccjit
https://gcc.gnu.org/onlinedocs/jit/ (ou d'autres bibliothèques de
compilation just-in-time).
Le point est que générer du code assembleur est facile, mais générer du
code assembleur efficace est très chronophage (ce n'est pas en vain que
GCC dépasse la dizaine de millions de lignes, dont la plupart sont
consacrées aux optimisations).
Il est usuel de passer à un programme un nom de ficher à ouvrir par
argument sur ligne de commande. En C, argc() sert à cela, en Ada le
"package" de bibliothèque ADA.COMMAND_LINE fait exactement le même
boulot. Vu de l'assembleur, toutes ces informations sont accédées par
une liste de pointeurs dans la pile en début d'exécution, un petit peu
de travail permet de lire les arguments (et aussi l'environnement)
comme en C.
Il se trouve que sous wheezy, je pouvais transmettre directement à la
fonction open du noyau (accédée par interruption 80h) ce pointeur en
pile. Avec jessie et le noyau cité ci-dessus (et, si mon souvenir est
bon, de même pour le noyau installé en été 2016), j'obtiens l'erreur
EFAULT, même en essayant sur compte root. Si je copie le nom de
fichier argument dans une zone mémoire du programme, tout marche bien.
Ce n'est pas une question de donnée puisque la copie ne change rien au
nom, 0 final compris. Est-ce un bug du noyau?
Probablement non. Un noyau bogué fait un crash système. Ce n'est pas le
cas. Je crois que les appels systèmes utilisent SYSENTER (en Linux
x86-64); si tu lis l'anglais voir
http://softwareengineering.stackexchange.com/a/343797/40065 (c'est moi
qui l'ai rédigé).
J'aurais utilisé strace à ta place (sur ton binaire). Puis gdb.
Question annexe: quand je me pose ce genre de questions, ne
devrais-pas pas fréquenter la liste des développeurs? Pourtant, je
suis développeur SOUS Linux, et non DE Linux.
Mon problème initial est du même ordre. Il est très connu, expliqué
par une note dans la page de manuel de sigaction. Le signal SIGFPE,
s'il est ignoré ou récupéré, provoque un bouclage permanent sur
l'instruction qui porte une division par zéro ou même 'idiv' sur plus
petit entier (négatif) divisé
