Re: usine à gaz des .h
Bonjour,
Philippe Deleval wrote:
J'essaie de construire un récupérateur d'erreurs en assembleur et,
pour récupérer les erreurs numériques traitées par le signal SIGFPE,
[...]
J'ai trouvé les symboles souhaités dans
/usr/include/i386-linux-gnu/sys/ucontext.h (appelé par
/usr/include/ucontext.h) sous un #ifdef __USE_GNU). Or, alors que les
identifiants génériques comme ucontext_t, mcontext_t, uc_mcontext ou
gregs, sont bien visibles, les REG_EAX, etc... ne le sont pas, gcc me
signale un identifiant non déclaré. Ce même si j'essaie d'assurer à la
main que __USE_GNU est bien défini avant le #include ucontext.h.
Je ne sais pas quel est le problème, mais à tout hasard, voici un
exemple rudimentaire qui a l'air de marcher sous Linux alors qu'il fait
référence à REG_RIP.
/* gcc -std=gnu99 -frounding-math sigfpe.c -lm */
#define _GNU_SOURCE
#define __USE_GNU
#include signal.h
#include fenv.h
#include stdio.h
#include string.h
#include ucontext.h
volatile double a, b, c;
volatile _Decimal64 d, e, f;
static void
handler (int sig, siginfo_t * siginfo, void * ucontext) {
// unsafe
char * descr = ;
if (sig == SIGFPE) {
switch (siginfo-si_code) {
case FPE_INTDIV: descr = integer divide by zero; break;
case FPE_INTOVF: descr = integer overflow; break;
case FPE_FLTDIV: descr = floating-point divide by zero; break;
case FPE_FLTOVF: descr = floating-point overflow; break;
case FPE_FLTUND: descr = floating-point underflow; break;
case FPE_FLTRES: descr = floating-point inexact result; break;
case FPE_FLTINV: descr = floating-point invalid operation; break;
case FPE_FLTSUB: descr = subscript out of range; break;
}
}
printf (%s (%s) @ 0x%lx\n, strsignal (sig), descr, siginfo-si_addr);
fflush (stdout);
ucontext_t *uc;
uc = (ucontext_t *) ucontext;
c = 42;
uc-uc_mcontext.gregs[REG_RIP] += 3;
}
int
main (void) {
struct sigaction sa;
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
sigaction (SIGFPE, sa, NULL);
feenableexcept (FE_ALL_EXCEPT);
d = 0.0DD;
e = 0.0DD;
f = d / e;
a = 1.0;
b = 0.0;
c = a / b;
printf (back!, %g %g %g\n, a, b, c);
fflush (stdout);
a = 0.0;
b = 0.0;
c = a / b;
printf (back!, %g %g %g\n, a, b, c);
fflush (stdout);
a = 0.0;
b = 0.0;
c = a / b;
printf (back!, %g %g %g\n, a, b, c);
fflush (stdout);
return 0;
}
Cordialement,
--
Marc Mezzarobba
--
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/lotp9d$aj2$1...@ger.gmane.org
course sur SIGFPE
Bonjour à tous. Je ne peux que relancer mon sujet en essayant d'être plus clair. (i) je cherche à récupérer depuis l'assembleur le signal SIGFPE, qui correspond aux erreurs numériques déclenchées par le coprocesseur mathématique, mais aussi par le processeur (instruction div ou idiv). (ii) en défrichant à l'aide de C (et de gcc -S), j'ai vu un comportement très spécial du préprocesseur de gcc: les symboles d'indices pour indexer le type tableau greg_t (défini dans sys/ucontext.h) ne sont pas visibles. Pour le premier point, j'ai progressé en assembleur. Le nombre de Memory access violation que j'ai récupéré depuis des programmes écrits tant en C (en contournant le point (ii)) qu'en assembleur m'a convaincu que le pointeur sur un ucontext_t passé à mon handler était NULL ! D'où l'idée que j'étais directement dans le bon contexte. Du coup, il suffit de remplacer le 'ret' en fin de handler par un 'pop' suivi d'un 'jmp' pour obtenir le comportement que je souhaitais: traiter l'erreur en un point de chute précis de mon programme. Ce qui n'est faisable qu'en assembleur! C peut arriver à un résultat proche avec setjmp / longjmp, mais pas tout à fait ce que je cherche. Linux fonctionne donc pour sigaction très différemment de Solaris, au vu de l'exemple trouvé sur Internet. Du coup, pas besoin du troisième paramètre du handler, de type (de fait) *ucontext_t. Toutefois il me reste un problème: une fois le handler utilisé, SIGFPE retrouve son comportement par défaut. Voici ce que j' obtiens avec mon programme envoyant en boucle à la procédure effectuant le travail les valeurs 0, 1, 2 et 3, le dividende étant 6: SIGFPE récupéré Valeur reçue sur eax: . Valeur reçue sur eax: 0006. Valeur reçue sur eax: 0003. Valeur reçue sur eax: 0002. La valeur est celle mise en place par le traitement d'erreur. 6, 3 et 2 sont les résultats de division par 1, 2 et 3, ensuite 0 est de nouveau transmis, mais le message pour SIGFPE du système n'est même pas dans le stderr du programme, je présume que c'est le shell qui me fait le compte-rendu. Ce qui montre que le handler dans le programme a cessé d'être pris en compte. J'ai fait plusieurs essais en réutilisant sigaction, je n'ai pas jusque là trouvé de solution. Pour si quelqu'un est curieux, je joins le programme assembleur. N.B.: il est parfaitement autonome (à condition d'utiliser nasm). A propos, je ne veux pas de polémique sur l'usage de int 80h, pour moi, quand je ne travaille pas avec C, je n'utilise pas C, point. La portabilité n'est pas un objectif quand on travaille en assembleur. Pour le deuxième point, si j'ai (maladroitement semble-t-il) intitulé mon message précédent usine à gaz des .h, c'est que je ne programme pas seulement en assembleur, mais aussi en Ada. A chaque fois que je veux appeler un service du système, c'est franchement la galère pour l'interfacer, je souhaiterais que le préprocesseur soit capable de fournir une meilleure documentation sur les données à utiliser (gcc -E élimine en les interprétant les #define, or ce sont eux qui définissent toutes les constantes). La programmation courante en C ne fait pas apparaître le problème, seulement voilà, C est un langage que l'on peut qualifier de bas niveau (citation tirée de Le langage C, Norme ANSI, de Brian W. Kernighan et Denis M. Ritchie, deuxième édition, traduction française Masson / Prentice Hall 1997, p. 2, justifiée très simplement dans les lignes suivantes). Je ne l'utilise que pour des jeux d'essai ou de petites fonctions servant d'interfaces. 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 30 juin 2014 ; ; 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 ave cles 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!) ; BITS 32 GLOBAL _start SECTION .text %idefine sys_exit 1 %idefine
[HS] Re: course sur SIGFPE
Le mardi 1 juillet 2014, 15:17:22 Philippe Deleval a écrit :
Bonjour à tous.
’jour,
Je ne peux que relancer mon sujet en essayant d'être plus
clair.
Ce qui ne l’empêche pas d’être toujours HS.
Ça ne me dérange pas trop que tu essaies encore cette liste
mais, STP, mets et conserve le drapeau [HS].
(i) je cherche à récupérer depuis l'assembleur le signal
SIGFPE, qui correspond aux erreurs numériques déclenchées par
le coprocesseur mathématique, mais aussi par le processeur
(instruction div ou idiv).
On avait compris…
[… réordonné …]
Pour le premier point, j'ai progressé en assembleur. Le nombre
de Memory access violation que j'ai récupéré depuis des
programmes écrits tant en C (en contournant le point (ii))
qu'en assembleur m'a convaincu que le pointeur sur un
ucontext_t passé à mon handler était NULL !
Euh, t’as bien mis le drapeau SA_SIGINFO ?
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é ?
[… on reprend …]
(ii) en défrichant à l'aide de C (et de gcc -S), j'ai vu un
comportement très spécial du préprocesseur de gcc:
les symboles d'indices pour indexer le type tableau greg_t
(défini dans sys/ucontext.h) ne sont pas visibles.
[…]
Pour le deuxième point, si j'ai (maladroitement semble-t-il)
intitulé mon message précédent usine à gaz des .h, c'est
que je ne programme pas seulement en assembleur, mais aussi
en Ada. A chaque fois que je veux appeler un service du
système, c'est franchement la galère pour l'interfacer, je
souhaiterais que le préprocesseur soit capable de fournir une
meilleure documentation sur les données à utiliser (gcc -E
élimine en les interprétant les #define, or ce sont eux qui
définissent toutes les constantes). La programmation courante
en C ne fait pas apparaître le problème, seulement voilà, C
est un langage que l'on peut qualifier de bas niveau
(citation tirée de Le langage C, Norme ANSI, de Brian W.
Kernighan et Denis M. Ritchie, deuxième édition, traduction
française Masson / Prentice Hall 1997, p. 2, justifiée très
simplement dans les lignes suivantes). Je ne l'utilise que
pour des jeux d'essai ou de petites fonctions servant
d'interfaces.
Ça 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 :
/* Number of each register in the `gregset_t' array. */
enum
{
REG_R8 = 0,
# define REG_R8 REG_R8
//…
Le enum définit des constantes C de valeur entière (int) qui se
suivent, en commençant par 0. Les #define utilisent ces valeurs
pour définir des macros pour CPP correspondant à ces valeurs.
Ouais, chaque symbole est utilisé trois fois, dans l’ordre :
— comme champ de l’enum ;
— comme nom de macro CPP ;
— pour obtenir la valeur du champ de l’enum.
C’est beau CPP…
Donc si tu veux tripoter cette structure C dans un langage
non-C, tu dois toi-même récupérer l’ordre de ces registres pour
les mettre dans une jolie construction du langage que tu
utilises, p.ex. :
%idefineREG_R8 0 ;
%idefineREG_R9 1 ; etc.
(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.))
--
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/14347258.i4n2feXt9M@earendil
[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
Essayez le célèbre Papillon Magique dans vos mailings
Si cet email ne s'affiche pas correctement, veuillez cliquer ici Surprenez vos clients, vos prospects avec l'incroyable Papillon Magique qui s'envole de vos mailings Votre Pack Mailing complet à partir de 100 unités seulement ! Taux de retour record : 20% des centaines de références dans le monde... Informer, prospecter, lancer un nouveau produit, dynamiser une image de marque,... Magic Flyer® est une invention francaise © and Patent Magic Flyer International Tous droits réservés Tel : 04 90 94 31 00 - magicfl...@magicflyer.com - www.magicflyer.com Si vous ne souhaitez plus recevoir de-mail de notre part : Désabonnement
