Posté le 15/07/2018 12:09
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 56 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 18/08/2022 11:46 | #
Les versions alpha ont à nouveau été mises à jour avec une nouvelle fonctionnalité : le tracé de fonction de C dans C, avec au choix par exemple la commande plot((x+i*y)^2) ou pour des fonctions dépendant directement sans complexe sans passer par la partie réelle et imaginaire, plot3d(x^2) (on ne peut pas utiliser directement plot(x^2) car cela est compris comme un graphe de R dans R). Le module du complexe résultat est représenté selon z, l'argument avec une couleur de l'arc en ciel.
En codant cela, j'ai rencontré un problème assez déconcertant: pour avoir les couleurs de l'arc en ciel, j'avais créé un tableau constant déclaré comme suit
struct int4 {
int u,d,du,dd;
int4(int u_,int d_,int du_,int dd_):u(u_),d(d_),du(du_),dd(dd_) {}
};
const int4 tabcolorcplx[]={
{63488,47104,30720,14336},
{63489,47105,30720,14336},
{63491,47106,30721,14336},
...
Ca compile correctement mais le tableau n'est pas initialisé correctement par le chargeur. Il ne contient que des 0. J'ai alors essayé de remplacer l'initialisation {} par des int4() mais sans succès.
J'ai finalement du déclarer le tableau sans const et rajouter le code suivant
if (tabcolorcplx[0].u==0){
for (int i=0;i<126;i++){
tabcolorcplx[i].u=arc_en_ciel(i,1);
tabcolorcplx[i].d=arc_en_ciel(i,.75);
tabcolorcplx[i].du=arc_en_ciel(i,.5);
tabcolorcplx[i].dd=arc_en_ciel(i,.25);
}
}
Citer : Posté le 22/08/2022 22:18 | #
Intéressant comme bug de chargement. Je soupçonne que la section n'est pas linkée correctement parce que le compilateur C++ a tendance à donner des noms bizarres aux sections et il se pourrait que le linker script ne la repère pas.
Tu peux tester cette théorie très rapidement en utilisant le tableau initialisé normalement et en affichant les sections du fichier ELF avec sh3eb-elf-objdump -h.
Citer : Posté le 23/08/2022 15:39 | #
Si le tableau est declare en const, sh3eb-elf-objdump -C -t khicas.elf me renvoie
Si non déclaré en const,
Citer : Posté le 23/08/2022 15:51 | #
Ah ben oui .bss c'est initialisé à 0 par le chargeur. Peux-tu regarder le symbole dans le fichier objet qui contient tabcolorcplx ?
Citer : Posté le 23/08/2022 19:22 | #
Voila ce que me renvoie
sh3eb-elf-nm zdisplay.o | grep tabcolorcplx
00000004 B __ZN4xcas12tabcolorcplxE
Citer : Posté le 23/08/2022 19:24 | #
Oups, c'était la version sans const, la version avec const renvoie
00000014 b __ZN4xcasL12tabcolorcplxE
Citer : Posté le 23/08/2022 19:30 | #
Donc il est déjà dans la section BSS, ie. initialisé à 0.
À bien y réfléchir, si le tableau est static const il devrait être initialisé correctement. S'il n'est pas const il devrait être copié dans la pile au début de la fonction...
Citer : Posté le 23/08/2022 20:46 | #
C'est une variable globale.
Citer : Posté le 24/08/2022 16:55 | #
Ta structure int4 elle est POD ? Je me demande si un constructeur ne pourrait pas interférer. Sinon je vois pas pourquoi un tableau comme ça serait pas initialisé. Si tu fais un int tabcolorplx[][4] = { ... } sûrement il est initialisé correctement (dans la section .data/.rodata) ?
Citer : Posté le 24/08/2022 21:10 | #
Il y a juste le constructeur d'initialisation qui est pratique à d'autres endroits (pas indispensable non plus). Le même code ne pose pas de problème avec la Numworks et TI nspire CX.
Citer : Posté le 24/08/2022 22:58 | #
Désolé pour le retour mou. J'ai testé, je pense avoir trouvé. Si on reprend depuis le début :
struct int4 {
int u,d,du,dd;
int4(int u_,int d_,int du_,int dd_):u(u_),d(d_),du(du_),dd(dd_) {}
};
const int4 tabcolorcplx[]={
{63488,47104,30720,14336},
{63489,47105,30720,14336},
{63491,47106,30721,14336},
};
Le symbole est bien dans .bss :
% sh-elf-objdump -C -t a-sh.o
(...)
00000000 l df *ABS* 00000000 a.cpp
00000000 l O .bss 00000030 tabcolorcplx
00000000 l F .text 000000b0 __static_initialization_and_destruction_0(int, int)
000000b0 l F .text 00000024 _GLOBAL__sub_I_a.cpp
00000000 l .group 00000000 ZN4int4C5Eiiii
00000000 w F .text._ZN4int4C2Eiiii 0000005e int4::int4(int, int, int, int)
00000000 w F .text._ZN4int4C2Eiiii 0000005e int4::int4(int, int, int, int)
Une symbole dans la section .bss n'est pas initialisé ou initialisé à 0, donc clairement le compilateur ne compte donc pas sur l'initialisation des sections de données pour assigner ta variable.
À la place, l'initialisation se fait via un constructeur (pas au sens C++, juste une fonction lancée au démarrage du programme) qui est révélé par l'existence d'une section .ctors contenant un pointeur de 4 octets :
a-sh.o: file format elf32-sh
Sections:
Idx Name Size VMA LMA File off Algn
5 .ctors 00000004 00000000 00000000 00000170 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
À partir de là c'est facile (supposant le code que j'ai trouvé dans la version en ligne de giac90.tgz). Aucun des linker scripts (relativement simples) que tu utilises ne collecte ces constructeurs. Je n'ai pas trouvé le loader dans l'archive, mais l'idée générale c'est que tu veux collecter les constructeurs comme ceci et ensuite les appeler comme ceci, bien sûr après avoir initialisé les sections.
Citer : Posté le 25/08/2022 10:28 | #
Hum, je crois que pour le moment je vais laisser l'initialisation en RAM, je vais rajouter un commentaire dans le source.
Citer : Posté le 31/08/2022 17:19 | #
Je viens de passer les versions en 2 addins en version stable de KhiCAS. La doc a ete mise a jour
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/khicasio.html#sec3
et je suis en train de terminer un document sur la nouvelle application de geometrie 2d et 3d de KhiCAS
https://www-fourier.univ-grenoble-alpes.fr/~parisse/irem/geo.html
N.B.: La Graph 90 a sa propre application de geometrie 2d mais elle a enormement moins de fonctionnalites!
Citer : Posté le 01/09/2022 18:12 | #
Je suis sur un crash assez inexplicable (sur le calcul de integrate(abs(cos(x)),x,0,pi)), le crash affiche address(R), en df1ed41f (pc=10).
Ca correspond a une adresse en memoire? Merci!
Citer : Posté le 01/09/2022 21:30 | #
Ce n'est pas une adresse mémoire, c'est du code. Spécifiquement si ma mémoire est bonne c'est les 4 octets que tu obtiens si tu lis à NULL.
Cela suggère qu'un pointeur sur fonction a été lu, non pas à sa place, mais à NULL.
Citer : Posté le 01/09/2022 23:03 | #
Merci! Donc ca ne m'aidera pas a localiser l'erreur, du coup je me lance avec le debugger sur l'emulateur. C'est loin d'etre aussi pratique que le debugger sur PC mais c'est quand meme un progres enorme par rapport a avant, en particulier en l'utilisant en parallele avec le debugger sur PC sur le meme code.
Du coup, je viens de remettre a jour tous les binaires, j'ai corrige 2 ou 3 bugs dans des calculs d'integrale en testant une partie de mes exos pour les L2 physique. Je vais surement en trouver encore dans les prochains jours.
Citer : Posté le 02/09/2022 12:07 | #
J'ai toujours un probleme, tres certainement lie a l'allocation memoire, dont je n'arrive pas a determiner l'origine precise. Symptome: si on fait
Plus precisement, j'ai fait a plusieurs reprises hbreak zseries.cc:2392, puis c 3 fois, au 3eme arret hbreak zseries.cc:2006 puis c, puis hbreak zseries.cc:617 dans la fonction pdiv ou j'ai vu plusieurs fois le crash. Mais il semble aussi s'etre produit dans pcompose et lors de ma derniere tentative,c'etait avant le 2eme hbreak, et l'adresse du PC lors du crash se situait dans le code de kmalloc.
Du coup je change dans main.cc:1196 static_ram.is_default = 0; dans le code d'initialisation de l'arene et la le calcul arrive a son terme sans problemes!
Je vais tester la stabilite dans cette configuration, j'en ai besoin rapidement pour preter les calcs aux etudiants et la recherche de ce genre de bugs est long et hasardeux. Si je comprends bien ca ne change rien en terme de total de memoire accessible, c'est juste l'ordre qui change.
Citer : Posté le 02/09/2022 13:38 | #
Voila maintenant qu'il m'arrive le meme probleme sur ma calc que celui signale par un utilisateur de fxcg50, pas possible de lancer khicas90 overclocke alors que j'arrive a lancer khicas50 non overclocke!!!
Citer : Posté le 02/09/2022 13:39 | #
Merci. Ça change beaucoup la mémoire accessible parce que l'arène est invisible pour malloc() ; tu as essentiellement supprimé l'arène, donc malheureusement je pense que ce patch doit te créer des problèmes ailleurs.
C'est vraiment dur de reproduire les problèmes avec KhiCAS pour moi ; j'admets ne pas être sûr d'avoir le temps de faire un test abouti dans les prochaines semaines (thèse + déménagement + etc). Un bug de kmalloc n'est bien sûr pas exclu. Je me permets de noter que l'introduction de kmalloc a révélé par des crashs dans _kfree pas mal de buffer overflows invisibles avant, et à date aucun bug dans l'allocateur lui-même. Il me paraît donc légitime de voir si un buffer overflow peut exister de ton côté ; un petit coup de valgrind, si tu y as accès, devrait tester cette théorie sans nécessiter de gros efforts.
Citer : Posté le 02/09/2022 14:31 | #
Oui, je suis assez convaincu que l'erreur est quelque part dans khicas, pas dans kmalloc, le fait d'utiliser kmalloc accelere juste un peu le crash vs le malloc sur le heap. Malheureusement, je n'arrive pas a detecter de problemes en utilisant valgrind sur le meme code sur PC. Enfin, ce n'est pas tout a fait le meme code a cause des specificites de la casio, en particulier stl vs ustl et endianness.
Ca fait 6h que je suis en train de faire du parallel debug entre gdb et cross-gdb, tout a l'air de bien fonctionner jusqu'au moment ou ca crash sur l'emulateur. Du coup, peut-etre que tu as des suggestions pour ameliorer ma productivite sur le cross-debugger:
1/ peut-on faire un backtrace sur le cross-gdb avec l'emulateur lorsque la fenetre de crash apparait? Sur PC, je fais bt dans gdb et je peux voir les frames appelant le code qui crashe
2/ peut-on faire un output vers le cross-gdb sh3? Avec le cross-debugger arm et firebird-emu sur nspire, ca marche et c'est tres utile pour visualiser des giac::gen et des giac::vecteur parce que j'ai une fonction membre dbgprint() pour voir les valeurs de maniere comprehensible.
Citer : Posté le 02/09/2022 14:34 | #
Sur la question de l'overclock, il y a certainement un probleme avec clock_set_speed(5);
Lorsque je lance ptune et que je fais F5, je peux lancer KhiCAS avec overclock (le code clock_set_speed(5) s'execute sans probleme). Par contre ptune F1 (normal) puis KhiCAS avec overclock crashe. Symptome: l'ecran devient noir puis ca reboote au bout de quelques secondes.