Re: [HS] course vers SIGFPE
Bonjour à tous
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...
Le 01/07/2014 17:09, Sylvain L. Sauvage a écrit :
(...)
Je vois deux possibilités :
1. (peu probable) tu as collé un SA_RESETHAND dans un coin ;
J'ai fait beaucoup d'essais, avec ou sans le drapeau SA_RESETHAND, sans
variation de comportement.
2. ce que tu fais dans le gestionnaire de signal empêche le
réarmement automatique du signal.
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.
N.B.: ce n'est pas une affaire de coprocesseur ! C'est le processeur lui-même
qui déclenche l'interruption 5 quand un problème se pose avec 'div' ou 'idiv'.
Comme le coprocesseur déclenche la même interruption en cas de problème si ses
flags ont été configurés pour, la réaction du noyau Linux est la même: SIGFPE.
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. Où dois-je signaler un bug dans sigaction?
Cordialement
Philippe Deleval
; chapeau pour programmes ou modules écrits en assembleur
; inspiré du header suggéré par Jeff Duntemann (Assembly Language Step
; by Step, troisième édition, Wiley 2009)
;
; fichier source: fpe_asm.asm
; fichier produit: fpe_asm
;
; version 1.0
; Créé le 28 juin 2014
; Mis à jour le 2 juillet 2014, nettoyage des scories de la version C trouvée
; sur Internet
;
; Auteur: Philippe Deleval
;
; Description:
; version assembleur du programme de récupération de SIGFPE
; version avec détournement du 'ret' du handler
; Résultat des courses: le noyau enchaîne sur le handler de l'utilisateur
; avec le contexte qu'il aurait s'il était appelé par 'call' depuis le point
; ou le hardware a lancé 'int 5' (réaction aux erreurs de Floating Point,
; mais aussi aux divisions par zéro ou débordements de 'div' ou 'idiv'), ce
; que le noyau convertit en SIGFPE.
; Si ça marche sur la première captation de SIGFPE, je ne trouve pas le moyen
; de relancer et réinstaller le 'handler' après usage!
;
; N.B.: le programme principal appelle la procédure wrk avec les valeurs sur
; ebx 0, 1, 2, 3 cycliquement (effect des deux instructions 'inc eax' et
; 'and eax, 3' (i.e. ___0111 binaire).
;
;
; Commande d'assemblage: nasm -f elf fpe_asm.asm
; Commande d'édition de liens: ld -s -x -o fpe_asm fpe_asm.o (sauf si debug!)
;
;
; Compléments de documentation:
;
; tiré de bits/sigset.h:
;/* A `sigset_t' has a bit for each signal. */
;
;# define _SIGSET_NWORDS(1024 / (8 * sizeof (unsigned long int)))
;typedef struct
; {
;unsigned long int __val[_SIGSET_NWORDS];
; } __sigset_t;
;
; tiré de bits/sigaction.h et simplifié en assumant __USE_POSIX199309 !
;
;/* Structure describing the action to be taken when a signal arrives. */
;struct sigaction
; {
;/* Signal handler. */
;union
; {
; /* Used if SA_SIGINFO is not set. */
; __sighandler_t sa_handler;
; /* Used if SA_SIGINFO is set. */
; void (*sa_sigaction) (int, siginfo_t *, void *);
; }
;__sigaction_handler;
;
;/* Additional set of signals to be blocked. */
;__sigset_t sa_mask;
;
;/* Special flags. */
;int sa_flags;
;
;/* Restore handler. */
;void (*sa_restorer) (void);
; };
BITS 32
GLOBAL _start
SECTION .text
%idefine sys_exit 1
%idefine sys_read 3
%idefine sys_write 4
%idefine sys_sigaction 67
%idefine stdin 0
%idefine stdout 1
%idefine stderr 2
%define SIGFPE 8 ; code de SIGFPE d'après fpe_v0.s
; valeurs tirées de bits/sigaction.h
; Bits in `sa_flags'.
%define SA_NOCLDSTOP 1 ; Don't send SIGCHLD when children stop.
%define SA_NOCLDWAIT 2 ; Don't create zombie on child death.
%define SA_SIGINFO4 ; Invoke signal-catching function with
; three arguments instead of one.
%define SA_ONSTACK 0x0800 ; Use signal stack by using `sa_restorer'.
%define SA_RESTART 0x1000 ; Restart syscall on signal return.
%define SA_NODEFER 0x4000 ; Don't automatically block the signal when
; its handler is being executed.
%define SA_RESETHAND 0x8000 ; Reset to SIG_DFL on entry to handler.
%define SA_INTERRUPT 0x2000 ; Historical
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. 1 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
Re: [HS] course vers SIGFPE
Bonsoir je suis perplexe, j'ai fait deux variantes de mon programme assembleur 1°) avec correction du registre ebx qui déclenche la division par zéro: le signal est envoyé à répétition, la correction ne semble pas prise en compte! C'est bien mon handler qui répond à chaque fois. 2°) en éliminant la division par 0 et en déclenchant SIGFPE de l'extérieur par kill -s 8 : pas de problème, mon handler installé répond bien à chaque envoi. Alors pourquoi tout se passe-t-il normalement (du côté du handler et de sigaction au moins) dans ces deux cas et pas dans mon exemple initial? Je vais aller chercher mon bonheur ailleurs et reviendrai dire si j'ai trouvé une explication. Bien cordialement Philippe Deleval -- 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/53b5af06.9070...@wanadoo.fr
[HS] course vers SIGFPE
Rebonjour! Avec mes excuses pour Sylvain Sauvage, mon rédacteur de message m'a fait une blague curieuse (que je préfère emacs!) Le 01/07/2014 16:05, Sylvain L. Sauvage a écrit : (...) Euh, t’as bien mis le drapeau SA_SIGINFO ? Bien sûr! Il était là dès que j'ai repris l'exemple sur Internet, avant même que je le trouve dans un .h ! Et il est assez documenté dans la page de manuel de sigaction. j'ai d'ailleurs repris sigaction.h dans mon fpe_asm.asm. D'où l'idée que j'étais directement dans le bon contexte. D’où l’autre idée que tu n’as pas le contexte parce que tu ne l’as pas demandé ? Je m'entends, ce que j'appelle 'contexte', c'est le 'stack frame' ! Pas besoin de demander ce qu'on a déjà! L'exemple Solaris m'avait mis en erreur sur ce point. Le 'ret' du handler renvoie à l'instruction qui a déclenché l'interruption (int 5 convertie en SIGFPE par le noyau). Il semble que ce ne soit pas le cas sous Solaris. () Ce n’est pas du tout un comportement « spécial », c’est le comportement défini. Le pré-processeur, comme son nom l’indique, passe avant le compilateur. Que tu veuilles (option -S) arrêter la compilation à l’étape « compilation », c’est-à-dire avant l’étape « assemblage », ne change rien au fait que le pré-processeur passera avant l’analyse du code. Si tu veux les valeurs des macros (« constantes ») pour greg_t, il « suffit » de comprendre le code C de sys/ucontext.h : Mais tout ça est bien là dans mon fichier assembleur ! Pas dur de transformer des #define en %define (ou %idefine) de nasm et des /* ... */ en ; avec emacs! Et je sais ce que veut dire enum, c'est la moindre des choses quand on a été formé à Pascal et qu'on travaille en Ada. (Perso, je ferais une moulinette pour automatiser tout ça et, au moins, je dirais d’où viennent les données. (P.ex. sys/ucontext.h explique que certaines proviennent des en-têtes du noyau.)) j'ai bien envisagé cette moulinette (en Ada?), mais après tout, il me semble que cpp fait un boulot assez proche pour que ce soit l'affaire d'une option de gcc. D'ailleurs gcc a une option (dans les options générales) -fdump-ada-spec qui fournit des spécifications Ada (.ads). Mais ce sont des copies des .h, et sans les constantes, si ce n'est en commentaire Ada! j' attendrais mieux. Il me reste un problème: mon handler ne marche qu'une fois! Cordialement Philippe Deleval -- 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/53b2cdc8.2060...@wanadoo.fr
Re: [HS] course vers SIGFPE
Le mardi 1 juillet 2014, 17:03:36 Philippe Deleval a écrit : Rebonjour! Re’, […] Il me reste un problème: mon handler ne marche qu'une fois! Je vois deux possibilités : 1. (peu probable) tu as collé un SA_RESETHAND dans un coin ; 2. ce que tu fais dans le gestionnaire de signal empêche le réarmement automatique du signal. -- 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/2374533.ndRFf2qKch@earendil
