Discussion :

[homeostasie]

Bonjour,

Je pense que c'est dans ce forum que je dois m'adresser mais il est bien probable que je déborde du contexte.

Voilà, à la base je travaille sous VxWorks et je me dois de développer des outils post mortem suite à un crash d'une target.

Ce que je compte faire, c'est mémoriser notamment la valeur du compteur porgramme avant le crash dans une section de mémoire NVRAM, qui représente l'adresse de la dernière instruction lue.

Connaissez vous un moyen d'obtenir à partir de cette adresse, l'instruction C ou la ligne de code associée et non le code assembleur? Quoique même obtenir le code assembleur serait déjà une bonne chose...

Sinon avez vous des idées qui pourraient m'aider et m'orienter vers une réflexion différente?

Je vous remercie. Bonne journée

Nicolas

[emardjean]

Si c'est juste pour du debug, il me semble qu'il existe un mode dans vxwork qui permet une sauvegarde automatique, dans un buffer tournant, des denieres instruction joues.C'est instructions peuvent être relu par un outil( desole, j'ai oublie le nom) au reboot de l'application.

[homeostasie]

Peut être que l'outil en question est WindView ou CrossWind...En fait, ce qu'il serait le plus pratique, c'est à partir d'un shell, pouvoir à l'aide de fonction intégrée ou à développer, d'obtenir la ligne de code ou l'instruction C définit par l'adresse dans le compteur programme (PC). Celle ci est récupérée après un reboot.

Ceci permettrait suite à un crash, de savoir sur quelle ligne, la target s'est planté.

En utilisant des commandes de WindShell, je peux connaître par déduction la fontion ou la tâche à laquelle correspond l'adresse de l'intruction du compteur programme. Puis il m'est possible d'obtenir le code assembleur. Mais il serait bien plus pratique et plus facile à lire du code C que de l'assembleur pour comprendre ou se situe le problème.

Qu'en pensez vous?

Merci

Nicolas

[fearyourself]

Bonjour,

Je pense que c'est dans ce forum que je dois m'adresser mais il est bien probable que je déborde du contexte.

Voilà, à la base je travaille sous VxWorks et je me dois de développer des outils post mortem suite à un crash d'une target.

Ce que je compte faire, c'est mémoriser notamment la valeur du compteur porgramme avant le crash dans une section de mémoire NVRAM, qui représente l'adresse de la dernière instruction lue.

Connaissez vous un moyen d'obtenir à partir de cette adresse, l'instruction C ou la ligne de code associée et non le code assembleur? Quoique même obtenir le code assembleur serait déjà une bonne chose...

Sinon avez vous des idées qui pourraient m'aider et m'orienter vers une réflexion différente?

Je vous remercie. Bonne journée

Nicolas

Pour retrouver la ligne en C:

- Impossible. Le code C étant générer souvent en plusieurs passes, de façon différente par rapport aux options utilisées, chaque compilateur faisant des choses différentes, je ne vois pas comment à partir du PI on peut trouver la ligne du code C associé.

- Le code Assembleur, non plus. Du moins pas directement. Lors de la génération du code binaire, beaucoup de choses disparaissent du fichier assembleur "lisible par l'homme".

- Le numéro de l'instruction dans la fonction? Oui.

En étudiant l'exécutable (donc le format ELF), on peut savoir dans quelle fonction se trouve le pointeur d'instruction, donc si on sait interpréter les instructions on pourra descendre jusqu'à obtenir l'adresse du pointeur d'instruction (vu que maintenant les instructions n'ont pas toujours la même taille...)...

A ce moment là, on pourrait sûrement aller dans le code assembleur, chercher la ligne de la fonction et à la limite donner la ligne.

Mais c'est 2 projets séparés:

- Chercher le numéro de l'instruction dans le code binaire
- Donner l'association dans le code assembleur

Et encore, cela suppose qu'entre le stade où le compilateur sort le code assembleur "lisible" par l'homme et le stade où code binaire est généré, le compilateur ne change plus rien.

Jc

[homeostasie]

Le numéro de l'instruction dans la fonction? Oui.

En étudiant l'exécutable (donc le format ELF), on peut savoir dans quelle fonction se trouve le pointeur d'instruction, donc si on sait interpréter les instructions on pourra descendre jusqu'à obtenir l'adresse du pointeur d'instruction (vu que maintenant les instructions n'ont pas toujours la même taille...)...

A ce moment là, on pourrait sûrement aller dans le code assembleur, chercher la ligne de la fonction et à la limite donner la ligne.

Mais c'est 2 projets séparés:

- Chercher le numéro de l'instruction dans le code binaire
- Donner l'association dans le code assembleur

Déjà merci pour ces renseignements qui me donne une meilleur idée de l'ampleur du travail.

En fait, qu'entends t'on par le numéro de l'instruction? Je ne suis jamais descendu au niveau du code binaire, va falloir que je m'y penche...

C'est bizarre car je pensais avoir l'adresse du pointeur d'instruction, notamment en sauvegardant la dernière valeur étant dans le PC(Program Counter) avant le crash. Si ce n'est pas l'adresse du PI, que cela représente t'il? Est cette valeur qui me permettrait de savoir dans quelle fonction se trouve le pointeur d'instruction?

Grossomodo, via le shell, je te montre ce que je fais:
(Je précise qu'à ce jour, je n'ai encore rien programmé mais je pense être capable de récupérer la dernière valeur du pc pour la tâche en cours avant crash de la cible).

Point d'entrée de la fonction AllocDebug: 0x00084bb4 (Je pars du principe que l’ adresse dans le PC est 0x00084bb8 et que c'est la dernière instruction exécutée avant crash).

A l'aide de la commande shell lkAddr, j'obtiens ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-> lkAddr 0x00084bb8
0x00084a10 EssaiShow                 text
0x00084bb4 AllocDebug                text
0x00085bec RDS_GenerateFormatEvent   text
0x000860e0 RDS_GenerateEventN        text
0x00088a2c _Z22PTRDS_ConnectSlaveShowPc text
0x00089c58 RDS_OldRdsEnableSet       text
0x00089cb4 RDS_OldRdsDisableSet      text
0x0008a4b4 PTRDS_MainEntryPoint      text
0x0008ac80 PTRDS_ModuleInit          text
0x0008b16c RDS_ModuleInit            text
0x0008b5b4 PTRDS_EnableEventDebug    text
0x0008b608 PTRDS_DisableEventDebug   text
value = 0 = 0x0

J'en déduis donc la fonction AllocDebug comme source de problème.

A l'aide de la commande shell "l", j'obtiens les 10lignes assembleur démarrant à ce point d'entrée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
-> l 0x00084bb4
                        AllocDebug:
0x84bb4  9421fff8    stwu        r1,-8(r1)
0x84bb8  7c0802a6    mfspr       r0,LR
0x84bbc  9001000c    stw         r0,12(r1)
0x84bc0  3c600171    lis         r3,0x171 # 369
0x84bc4  60631718    ori         r3,r3,0x1718
0x84bc8  480626b5    bl          0xe727c # malloc
0x84bcc  2f830000    cmpi        crf7,0,r3,0x0 # 0
0x84bd0  40be0024    bc          0x5,30, 0x84bf4 # 0x00084bf4
0x84bd4  4811a995    bl          0x19f568 # 0x0019f568
0x84bd8  80630000    lwz         r3,0(r3)
value = 543708 = 0x84bdc = AllocDebug + 0x28

Je déduis donc mfspr r0,LR comme source du bug.
Maintenant, comment peut on déduire la ligne C, du moins si vous avez une idée ?
Savez vous ce que représente la valeur qui pourrait suivre l’adresse de l’instruction 0x84bb8 ?

Evidemment, retrouvé l’erreur se ferait manuellement dans ce cas mais j’aimerais faire par la suite, une routine qui fournirais la ligne C en question en m’appuyant sur cette démarche.

Qu’en pensez vous ? Ca fait beaucoup de question….

Merci de votre aide et de vos idées.

Nicolas

[gege2061]

Bonjour,

A la première lecture je pensais que tu voulais faire cela dans le code du programme (un gestionnaire de bug intégré) mais apparemment non ?
Donc si je ne me trompe pas, tu peux utiliser gdb (en compilant ton programme avec les options de débuggage, -g avec gcc) et il fait le parrallèle entre l'exécution et les sources. Tu peux aussi récupérer les valeurs des registres...

[homeostasie]

A la première lecture je pensais que tu voulais faire cela dans le code du programme (un gestionnaire de bug intégré) mais apparemment non ?
Donc si je ne me trompe pas, tu peux utiliser gdb (en compilant ton programme avec les options de débuggage, -g avec gcc) et il fait le parrallèle entre l'exécution et les sources. Tu peux aussi récupérer les valeurs des registres...

Oui tout à fait, au final je désire faire tout cela dans un code programme. Ce que je voulais mettre ici en évidence c'est la méthode que je pourrais adopter en me basant sur le principe de ces fonctions de debug.

Nicolas