(HS=3f) probl=c3=a8mes de programmation

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.

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!

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?

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é par -1.

J'ai observé les comportement de l'assembleur, de C et de Ada sur ce
genre de problème et Ada, par sa norme même, est tenu de récupérer ce
signal en le transformant en l'exception CONSTRAINT_ERROR. j'aimerais
faire de même, donc, depuis la routine de traitement du signal,
détourner le retour. Y a-t-il un moyen de le faire sans aller bricoler
directement dans la pile?

Si quelqu'un a des réponses, je serais bien heureux d'avoir des
conseils, ne serait-ce que sur la question: dois-je aller dans la liste
des développeurs?

Amicalement

Philippe Deleval