Forum TI-Planet.org

Salut à tous,
Je poste ce topic car j'ai des problèmes à faire tourner des programmes qui marchaient sous l'émulateur, mais pas sur la nSpire réelle avec Ndless.

- Tout d'abord, il semble que tout programme qui a été compilé sans la chaîne PRG ne puisse pas être converti par MakeTNS (Message "Failed !"). Est ce bien cela qui est la cause du fail de conversion en tns, ou autre chose ? - c'est le cas pour l'émulateur de game boy il me semble.

- Ensuite, j'ai compilé mon programme perso (qui tourne bien sur émulateur) avec l'ajout de

Code: Select all

asm(".string "PRG"n");

au dessus du main() seulement, puis en compilant avec le fichier syscalls.c en plus (geogeo ou ExtendeD : à quoi sert ce fichier exactement ?).
Dans les deux cas, la conversion en tns se passe bien, mais à l'exécution : plantage : écran tout blanc.
Je me demande donc : que faire pour compiler des binaires qui ne plantent pas à l'exécution ?

Bon bon bon, voilà tout... J'ai mis en emphase les questions principales qui structuraient ma prose... ce n'est pas pour être agressif, mais pour mieux s'y retrouver

Je n'ai pas le temps de tester...


Mais Levak m'a signalé un problème lui aussi avant de partir.

syscalls implémente certaines fonctions requises par la bibliothèque C newlib.
Si tu n'utilises pas de fonctions de cette bibliothèque, tu pourrais envisager de compiler avec l'option -nostdlib.

Ndless peu être installé sur une image nspire_emu, ça peut permettre de débugger. Par contre placer un breakpoint en début de programme peut être un peu délicat, puisque le code est copié en RAM dans un bloc alloué dynamiquement, l'adresse varie.

Tu peux essayer par exemple de mettre un asm("_loop: b _loopn"); en début de programme, lancer le programme sous nspire_emu, ouvrir le debugger nspire_emu, repérer l'adresse de l'instruction qui suit. Puis redémarrer nspire_emu, poser un breakpoint sur cette adresse, et relancer le programme sans "loop".

Tu peux aussi essayer d'émettre des logs RS232 depuis ton programme. Aujourd'hui c'est un peu bancale : il faut réactiver les interruptions (TCT_Local_Control_Interrupts(0); ce qui provoquera l'affichage de l'horloge, c'est pour ça qu'elles sont aujourd'hui désactivées), puis utiliser log_rs232("ma log");.

Je continue de travailler sur un GDB stub pour nspire_emu qui permettra à terme le debug de programmes C dans l'émulateur.

Attends, mon programme marche bien avec l'émulateur... tu veux dire qu'un programme marchant bien en "mode boot2" sur l'émulateur peut ne pas marcher avec Ndless ?

Ndless est aujourd'hui en l'état plus un ouvre-boîte qu'un kit de développement, il n'a pas encore servi à exécuter beaucoup de choses. Donc oui, tu peux avoir des surprises.

Hum, je me demandais : supporte t-il les variables déclarées static ? En avoir marche bien avec l'émulateur, mais est-ce cela qui pose problème avec Ndless ?

Effectivement, c'est sûrement le problème. Les variables statiques nécessitent du relogement ou du travail sur la MMU, ce que ne permet pas encore Ndless.

Mais comment ça se fait que, à la base sans relogement ni MMU à priori (?), ça marche sous l'émulateur ?

- Aurais tu un lien qui traite du relogement ?

On avait commencé à en discuter ici, il doit y avoir quelques liens parmi les postes : http://ti.yaronet.com/posts.php?sl=s=12 ... 9h=544#544

Mais effectivement c'est étrange que ça fonctionne sous émulateur, à moins que tu utilises l'option -Ttext pour spécifier l'adresse de base du boot2.

Ah, je commence à comprendre.
Je compile avec : arm-elf-gcc -T ldscript -Os -Wall -W -fpic -fno-merge-constants -nostdlib crt0.o main.c screen.c -o print.elf

Donc du coup, ça génère du code avec des adresses relatives (?)

- gcc -fpic : génère une GOT, accédée en relatif. Le loader s'occupe simplement du relogement des adresses de cette GOT. Chaque GOT relogée est dédiée à un process.

Mais ça bloque sur les variables static qu'il faudrait proprement charger, c'est ça ?

En gros, il faut créer un chargeur elf pour utiliser ces variables... c'est faisable ?
J'ai trouvé ceci, au fait : http://directory.fsf.org/project/libelf/
ça tournerait sur l'ARM ?