Obtenir ligne de code c à partir du compteur programme

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

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.

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

Citation:

---

Envoyé par 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

---

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

Citation:

---

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:

---

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:

---

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

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...

Citation:

---

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