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

[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. :
%idefine	REG_R8	0	;
%idefine	REG_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


Reply to: