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 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/2789966.cQ3lbyuCrD@earendil