[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: