Citer : Posté le 02/05/2021 18:17 | #

---

Le fichier en question est la « carte » de l'add-in, il est généré par ld quand tu finis de compiler. L'option était activée par défaut dans la version Makefile des projets, mais pour CMake ce n'est pas le cas. Tu peux l'ajouter comme ceci :


et après avoir recompilé regarde build-fx/map ou build-cg/map.

Il y a différentes sources d'exceptions dans la calculatrices, et l'une d'elles est une instruction nommée trapa. Son unique rôle est de créer une exception histoire que le noyau reprenne la main dans les noyaux où il y a un userland. C'est utilisé pour implémenter des syscalls ; le programme veut appeler un syscall, il exécute un trapa, le noyau voir l'exception qui n'en est pas une, et exécute un syscall. trapa prend un argument, et TRA c'est la valeur de cet argument.

Comme dans la calculatrice on n'utilise pas trapa, cette instruction n'est jamais la cause d'une System ERROR, et donc la valeur affichée à l'écran n'a jamais de sens. Ça peut être utile pour debugger en situations très extrêmes où on veut juste un panic, et dans ce cas on peut mettre un argument différents à différents endroits du code et la valeur de TRA indique par où on est passé.

Pour info, puisque ce topic a un nom assez générique et que je pense que d'autres personnes le liront, les informations les plus importantes sont:

1. Le nom de l'erreur (et le code à trois chiffre devant).
2. La valeur de PC, qui est l'endroit du code où l'erreur s'est produite ; en utilisant la carte de l'add-in ou en désassemblant l'ELF, on peut trouver dans quelle fonction c'est.
3. La valeur de TEA, qui lorsque l'erreur est lié à un accès mémoire (souvent le cas), indique à quelle adresse le code a accédé.

L'erreur la plus classique c'est soit TLB miss read/write soit Read/write address error. Le premier signifie que le code (PC) a accédé à une adresse (TEA) qui n'existe pas du tout. Le second signifie que le code (PC) a accédé à une adresse (TEA) mal alignée. Pour plus de détails sur l'alignement, voyez cette partie du TDM 19.

---

Citer : Posté le 02/05/2021 18:45 | #

---

C'est correct. Ce qui va compter ici (malheureusement) c'est de savoir qui l'a appelée, et ça c'est difficile si on ne peut pas inspecter la pile (stack unwinding), un truc plus élaboré qu'on n'a pas.

Cette fonction est appelée par keydown() et indirectement par getkey(). La variable à laquelle elle accède est bien là (cachée dans le fichier keysc à 0x08101460), et je serais surpris que cette fonction soit buggée à proprement parler.

Là si j'étais vous je m'intéresserais à trouver quel appel à keydown() ou getkey() dans le code provoque cette erreur.

---

Citer : Posté le 02/05/2021 19:02 | #

---

Aah, et ainsi keydev_keydown() accédait à un indice du tableau qui n'existait pas car il allait chercher des touches au-delà de la fin de la liste. Je pourrais ajouter une protection mais ça ne ferait que rendre le problème plus difficile à résoudre, donc je pense que je vais laisser le code comme ça.

---

Citer : Posté le 02/05/2021 19:22 | #

---

Ahah, c'était donc ça. Bien joué Tituya, l'enfer est fini.

Merci pour tout ces informations Lephé, ce topic sera sûrement utile à d'autres dans le futur

---