Re: [HS] course vers SIGFPE
Le jeudi 3 juillet 2014, 14:01:36 Philippe Deleval a écrit :
> Bonjour à tous
’jour,
> Petit délai dans ma réponse, J'ai encore fait pas mal de
> recherches sur Internet, 'SIGFPE sigaction' donne beaucoup de
> résultats sur google, dont près de la moitié sont des
> exemplaires ou des copies de la page de manuel de sigaction!
> Il faut vraiment pas grand chose pour faire un cours...
Ouaip.
Et les bouquins ne font guère mieux. Et s’éloigner de la
machine / du noyau ne change pas grand-chose : la plupart des
bouquins sur <LANGAGE> sont une resucée du standard (pas
toujours à jour) avec, si on a de la chance, un peu d’API et
sinon, le tutoriel de base.
Je les comprends presque au vu du temps que j’ai dû passer
pour écrire des exemples (C++) clairs et presque utiles pour
les quelques cours d’introduction à la programmation système
que j’ai donnés…
> Le 01/07/2014 17:09, Sylvain L. Sauvage a écrit :
>[…]
> > 2. ce que tu fais dans le gestionnaire de signal empêche le
> > réarmement automatique du signal.
J’ai dit une ânerie : le signal ne doit pas être réarmé, il
n’est juste pas remis à SIG_DFL après usage (ce qui est le cas
avec SA_RESETHAND ou en passant par signal(2)). (On peut le
vérifier dans les sources du noyau, dans get_signal_to_deliver()
dans kernel/signal.c.)
> J'ai fait un essai minimal où le handler ne fait que détourner
> le 'ret' vers l'instruction de mon choix (deux instructions:
> pop eax et jmp afferr !) Même comportement. Mon "programme
> principal" passe en boucle à la routine de travail 0, 1, 2,
> 3, 0, 1, 2, 3. la première fois qu'elle passe 0, mon handler
> fonctionne, la deuxième fois, processus terminé par SIGFPE!
>
> Je joins mon texte en assembleur (nasm), avec tous les
> commentaires qui en font une historique.
Je ne vois pas d’erreur (juste un tas de commentaires ;o) mais
j’ai arrêté l’assembleur à l’étape théorie (6502 en plus).
Je peux comprendre chaque instruction mais voir l’ensemble, et
surtout déboguer, m’est difficile (voire pénible ;o).
>[…]
> Si vraiment je suis trop hors sujet, à qui, quelle liste
> dois-je m'adresser? j'ai fait un tour dans la liste (!) des
> listes Debian, aucune n'est prévue pour ce genre de problème.
Comme je l’ai déjà dit, ça n’est pas une question qui concerne
seulement Debian (n’importe quelle distribution GNU/Linux avec
le même noyau doivent avoir le même comportement) donc il n’y a
pas de liste Debian pour ça.
Il te faut une liste de programmation système sur Linux en
assembleur. Si tu l’amènes bien, tu dois au moins pouvoir
trouver des pointeurs sur la LKML. Sinon, j’irais voir dans un
sous-groupe de comp.lang.asm ou comp.os.linux.
> Où dois-je signaler un bug dans sigaction?
À ceux qui en ont écrit le code de sigaction : les
développeurs du noyau, donc la LKML. Mais, je serais toi, je
vérifierais mes arguments avant de m’y frotter : il y a env.
10000 messages par mois et ils n’aiment pas vraiment le bruit,
surtout quand un utilisateur débarque du diable Vauvert pour
leur dire que leur code est bogué. Surtout que, depuis du C,
sigaction() fonctionne bien et le gestionnaire est bien appelé
une fois par signal¹.
¹ Ça dépend du signal et de la façon dont il est envoyé puisque
quand un SIGFPE est envoyé à cause d’un calcul, le calcul est
ré-exécuté (ou plutôt recommencé puisqu’il n’a pas été exécuté
jusqu’au bout la fois précédente), donc le signal est relancé.
Ce n’est pas le cas quand on passe par kill() ou avec d’autres
signaux.
--
Sylvain Sauvage
Reply to: