Posté le 15/07/2017 13:54
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 127 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 21/11/2021 17:12 | #
pourquoi est-ce que ce bout de code
dline(134, 99, 139, 99, C_BLACK);
affiche des lignes plus fines que ce bout de code ?
dline(256, 123, 251, 123, C_BLACK);
Citer : Posté le 21/11/2021 20:55 | #
Hmmm je me brise crâne a essayer de comprendre pourquoi cette ligne me renvoie une erreur.
J'aurai bien besoin d'un coup de main
{
const Vertex* vertices;
int vertices_length;
const Triangle* triangles;
int triangles_length;
};
Object* current_object = map->object[i];
int a = current_object->mesh->vertices_length;
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_bad_cast':
(.text.unlikely.__cxa_bad_cast+0x8): undefined reference to _abort'
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_bad_typeid':
(.text.unlikely.__cxa_bad_typeid+0x8): undefined reference to _abort'
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_throw_bad_array_new_length':
(.text.unlikely.__cxa_throw_bad_array_new_length+0x8): undefined reference to _abort'
collect2: erreur: ld a retourné le statut de sortie 1
Merci si quelqu'un saurait me dire la raison de cette erreur de compilation
Citer : Posté le 21/11/2021 21:17 | #
L'erreur est un peu obscure, mais en gros GCC a généré un appel à abort(). Ça veut dire qu'il a détecté un bout de code qui est tellement illégal qu'il est certain que ça va se produire (ie. il a réussi à prouver que ton programme fait un truc illégal peu importe ses entrées).
En général ça veut dire que tu déréférences un pointeur nul quelque part. J'ai déjà essayé d'être malin avec ça mais GCC avait toujours raison ; tu peux être sûr qu'li y a un bug quelque part dans ta logique.
Citer : Posté le 21/11/2021 22:29 | #
Ok, merci pour la piste.
Je saisi pourtant pas pourquoi m'empêche d'écrire ça
debug_pop("ok ok %i", a); // affiche 4
Vertex* vertex = (Vertex*) malloc(a * sizeof(Vertex)); // ça ça marche
Vertex* vertex2 = new Vertex[a] // marche pas;
Citer : Posté le 21/11/2021 22:46 | #
pourquoi est-ce que ce bout de code
dline(134, 99, 139, 99, C_BLACK);
affiche des lignes plus fines que ce bout de code ?
dline(256, 123, 251, 123, C_BLACK);
C'est la même épaisseur pour les deux. Est-ce que tu ne te fais pas avoir par le problème des sous-pixels de couleur qui sont dans l'ordre RGB ?
Ajouté le 21/11/2021 à 22:55 :
Ok, merci pour la piste.
Je saisi pourtant pas pourquoi m'empêche d'écrire ça
Nvm en fait c'est évident vu le message :
std::bad_array_new_length
C'est la levée dynamique d'exception au cas où la taille est invalide. Désolé tu n'as pas forcément de bug c'est dans les fonctions throw qu'il y a ces abort. J'ai lu trop vite.
La fxlibc fournit abort() depuis le 29 Mai. Tu dois avoir une version trop vieille, peux-tu recompiler stp ?
Ajouté le 21/11/2021 à 22:56 :
C'est moi ou on peut pas faire de class sur Gint ?
On peut, Ninestars en fait. Il te faut GCC compilé avec support de g++ mais aussi la lib standard C++, ce qui je l'admets est encore acrobatique pour l'instant : https://gitea.planet-casio.com/Lephenixnoir/sh-elf-gcc#notes-on-building-libstdc-v3
C'est en train de s'améliorer mais pas hyper vite parce que je nage pas mal, je vais pas le cacher.
Ajouté le 21/11/2021 à 22:58 :
Pour info tes erreurs :
main.cpp:(.text.startup+0x84): undefined reference to `__Znaj'
/root/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: main.cpp:(.text.startup+0xb4): undefined reference to `__ZdaPv'
collect2: error: ld returned 1 exit status
C'est parce qu'il a pas les opérateur new. Si tu compiles la lib C++ avec les instructions ci-dessus tu peux ajouter -lsupc++ à ton CMakeLists.txt et il les trouvera.
Tu peux faire des classes de base sans la lib techniquement mais tu auras vite des problèmes un peu dans tout les coins, je ne le recommande pas.
Citer : Posté le 22/11/2021 00:00 | #
Il y a pas de soucis
J'ai actuellement la version 2.31.1 de fixlibc
Avec visiblement un unique changement sur calloc.c
Je mets à jour.
git pull
cmake -B build-gint -DFXLIBC_TARGET=gint -DCMAKE_TOOLCHAIN_FILE=cmake/toolchain-sh.cmake
make -C build-gint install
Un git version me renvoie toujours 2.31.1 (je m'y prends peut-être mal)
Citer : Posté le 22/11/2021 08:13 | #
Oui alors git version te donne ta version du logiciel git, si tu veux la version du dépôt utilise plutôt git describe :
1.2.2-2-ge71f986
# Trois parties séparées par des tirets
# Première partie "1.2.2": dernier tag (ie. ta version)
# Deuxième partie "2": nombre de commits depuis ledit tag
# Troisième partie : identifiant du commit actuel
La version 1.1.0 doit donner abort(). Ta méthode de compilation est correcte. Tu es sur quel commit exactement (ie. que tu donne git describe) ?
Citer : Posté le 22/11/2021 22:14 | #
J'ai la version 1.2.2
git describe
>>> 1.2.2
Citer : Posté le 22/11/2021 22:19 | #
je remarque que le script ld pour gcc est pour les calculatrices sh3 a 6k de ram. dans le script il est écrit que les sh4 en ont 32. je peux remplacer 6 par 32?
Citer : Posté le 22/11/2021 22:26 | #
J'ai la version 1.2.2
git describe
>>> 1.2.2
Vérifie que c'est ça qui est installé, fais-lui lister les fichiers objets s'il le faut :
abort.c.obj
Supprime le dossier de compilation et recompile, vérifie que dans le CMakeLists.txt le fichier est bien là :
src/libc/stdlib/abort.c
Vérifie que le fichier compilé est bien là :
build-gint/CMakeFiles/fxlibc.dir/src/libc/stdlib/abort.c.obj
Et que le fichier source est là :
src/libc/stdlib/abort.c
Ça devrait pas être difficile à trouver cette histoire...
je remarque que le script ld pour gcc est pour les calculatrices sh3 a 6k de ram. dans le script il est écrit que les sh4 en ont 32. je peux remplacer 6 par 32?
Pas vraiment non, d'abord c'est pas 6 kio mais 8 kio sur SH3 ; donc il faudrait en enlever un bout. Ensuite cette zone est gérée un peu différemment sur SH4. La mémoire en plus est disponible via malloc() : utilise ça plutôt.
Citer : Posté le 23/11/2021 22:46 | #
Ok je vais regarder ça et je te dis merci
Sinon j'ai ajouté
#include <fxlibc/printf.h>
puis
__printf_enable_fp();
Mais un message à la compilation
libc.a(grisu2b_59_56.c.obj): in function _grisu2':
grisu2b_59_56.c:(.text+0x4d4): undefined reference to _ceil'
Citer : Posté le 23/11/2021 22:49 | #
Ah c'est étrange ça. L'algorithme Grisu2 qui est utilisé pour obtenir la représentation décimale des nombres flottants utilise la fonction ceil(). Rien d'inhabituel jusque-là. Elle est fournie par OpenLibm qui est linkée par gint. Est-ce que tu peux essayer avec VERBOSE=1 pour voir si -lopenlibm apparaît dans la commande de link ?
Citer : Posté le 23/11/2021 23:07 | #
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/libc.a(grisu2b_59_56.c.obj): in function `_grisu2':
grisu2b_59_56.c:(.text+0x4d4): undefined reference to `_ceil'
Citer : Posté le 23/11/2021 23:09 | #
L'ordre n'est pas bon. Dans gint il y a ceci :
(...)
INTERFACE_LINK_LIBRARIES "-lc;-lopenlibm;-lgcc"
Ce qui veut dire qu'il doit y avoir une autre dépendance qui inverse l'ordre. Je crois qu'il y a ça dans ton CMakeLists.txt :
Retire -lopenlibm -lc ou change l'ordre.
Citer : Posté le 23/11/2021 23:16 | #
J'ai retiré et ça fonctionne en effet
Hmmm sinon j'ai l'impression d'avoir un truc incohérent dans mon CMakeLists.txt :
COMPILE_OPTIONS "-Wp,-w;-Wno-missing-field-initializers;-Wno-maybe-uninitialized")
Citer : Posté le 23/11/2021 23:18 | # |
Fichier joint
mon CMakeLists.txt en PJ au cas où
Citer : Posté le 23/11/2021 23:19 | #
C'est juste des options spécifiques à ce fichier, parce qu'il y a dedans des constructions qui activent beaucoup de warnings donc je les ai coupés.
Citer : Posté le 23/11/2021 23:22 | #
Ah ok je comprend la ligne de commande du coup
Pour map.cpp en particulier tu as mis les option de compilation -Wp,-w;-Wno-missing-field-initializers;-Wno-maybe-uninitialized. Bien vu
Citer : Posté le 24/11/2021 14:00 | #
Quelques nouvelles par rapport à ce crash que tu avais, Ninestars. J'ai réussi à le réduire à collision(), ie. la boucle principale ne fais pas de draw(), juste un update(), dans lequel il n'y a que player_move(), dans lequel il n'y a que collision().
Je ne sais toujours pas où est le bug mais comme j'ai eu un crash similaire dans une version plus ancienne de gintctl je pense que c'est de mon côté. Je te dirai, cela dit.
Ajouté le 24/11/2021 à 16:47 :
Conformément aux observations originales, c'est bien lié à un timer. Ça ne surprend absolument plus personne à ce point, avec tous les indices qui y menaient. Tu as bien fait de désactiver le tien, malheureusement il reste toujours celui du clavier qui peut à lui tout seul créer le crash.
Pour savoir si c'est le timer ou le clavier le problème j'ai juste laissé le driver clavier allumé avec un timer qui ne fait rien ; comme ça crashe c'est la faute du timer.
J'ai réussi à reproduire en utilisant soit (1) une fonction clavier, ce qui ajoute le driver clavier au g1a et active son timer, ou (2) ton timer avec un callback qui ne fait rien.
Ça ne crashe que si j'utilise un ETMU, donc ça commence à être assez précis.
Citer : Posté le 24/11/2021 17:33 | #
Excellent, tu as réussi à bien cibler où le bug se produit. C'est déjà une bonne étape de franchie
Citer : Posté le 24/11/2021 21:49 | #
Le mécanisme qui semble être spécifiquement en cause c'est le système de callback de gint, par lequel durant une interruption on peut s'échapper de l'interruption pour revenir en mode utilisateur pour exécuter du code (par exemple un callback de timer).
Le fait de s'échapper n'est pas le problème ici, c'est juste le fait d'appeler la fonction gérant l'échappement qui cause le crash (même si la fonction ne fait rien). Le soupçon c'est que cette fonction est spéciale, elle est chargée dynamiquement à une adresse déterminée à l'exécution. C'est la seule fonction qui est traitée comme ça sur SH3 (edit : sur SH4 aussi). Il pourrait y avoir une condition spéciale qui interfère avec ce bout de mémoire après un certain temps ou certaines actions.
Ajouté le 25/11/2021 à 19:02 :
Le bug est résolu selon toutes observations. C'est bien le même truc qui causait ton 5×4 = 6912 et ça se produisait que sur SH3 parce que c'est dans un tout petit bout d'assembleur spécifique au SH3 que l'arnaque se trouvait.
Donc quel génie ce Yatis, et sinon dis-moi si tu recroises le problème.