Bon, je décris la méthode que j'utilise pour déboguer ce problème (j'utilise KTIGCC, mais TIGCC IDE fonctionne de la même manière):
1. Activer les informations de débogage:
Project / Options / Compilation / Generate debug information / OK
(Il faut aussi que la compression soit désactivée pour qu'on puisse déboguer, ici c'est déjà le cas.)
2. Project / Build (enfin bon, Run va aussi détecter que les options ont changé et recompiler, donc tu peux sauter cette étape)
3. Debug / Run
4. TiEmu ouvre le débogueur sur le code de démarrage de TIGCC. Je clique donc sur Continue dans la fenêtre titrée Source Window.
5. Maintenant on est au début de _main. Comme je ne sais pas où se trouve l'erreur, je fais encore une fois Continue pour lancer le programme normalement.
6. Le débogueur s'arrête sur le plantage en 0xfc6e. Regardons comment on est arrivés à cet endroit: dans la fenêtre Disassembly, je choisis Windows / PC trace.
7. La dernière addresse est 0x85e868 (une adresse en ROM). Je me place sur cette adresse dans la fenêtre Disassembly (g 0x85e868 Entrée): c'est un
jsr (%a1) (plus précisément celui de l'appel de programmes de AMS, mais il faut bien connaître AMS pour savoir ça

).
8. Malheureusement le PC trace ne contient pas suffisamment d'informations pour savoir d'où vient l'appel, je regarde donc la pile (Windows / Stack frame) et je retrouve à l'offset +4 ce qui a l'air d'être une adresse en RAM: 0x3f648. Je regarde donc cette adresse dans Disassembly. Hélas, c'est l'adresse du début du programme (ça se reconnaît au
move.l (%sp),(%sp) marqueur des commentaires _nostub), donc on oublie cette piste et on recommence en pas par pas.
9. On fait donc un Reset Calc dans TiEmu et on refait les étapes 3 et 4 pour revenir au début de _main. (Ici, TiEmu a planté en faisant Run (bogue de TiEmu évidemment), donc j'ai refait un Run, ce qui a réouvert TiEmu, puis le Continue.)
10. Cette fois-ci, on y va au pas par pas: Faisons "Next" (n) dans le Source Window. Répétons jusqu'au plantage. Plantage dans
barre_statut.
11. Je répète une fois de plus, mais cette fois-ci, à la ligne 83, je choisis "Step" (s) pour rentrer dans la fonction. Après des Next, je vois que l'appel à
DrawStr de la ligne 79 plante.
12. Regardons maintenant cette fonction
barre_statut de plus près: Tu alloues une chaîne de caractères de 41 octets sur la pile. Or, je compte un total de 43 octets (42 + le '\0' final) dans le résultat de ton
sprintf. Donc tu débordes ton buffer, détruis le contenu de la pile, et c'est en fait le retour de
barre_statut à la fonction appelante (juste après le DrawStr qui avait l'air d'être l'endroit du plantage - avec les optimisations, parfois la ligne indiquée n'est pas la bonne à 100%) qui plante.
=> C'est une erreur dans ton programme, qui par hasard n'était pas visible avec l'ancien GCC, mais l'est avec le nouveau.