TIGCC, KTIGCC, TiEmu et KDE - Page 1

Installe le comme moi : from source (les binaires fournis me font un 'Flotting point error').

PpHd (./2) :
Installe le comme moi : from source (les binaires fournis me font un 'Flotting point error').

Les binaires fournis sont prévus pour Fedora 7 minimum (bientôt ce sera Fedora 8), donc c'est normal qu'ils ne tournent pas sur ton antiquité. (Enfin, pour TIGCC, le tarball binaire est censé être plus portable, mais ne l'est pas vraiment en réalité parce que glibc change beaucoup en ces derniers temps, donc il va être abandonné bientôt, il n'y aura plus que les sources et les RPMs.)

Quant à la question de départ: KTIGCC nécessite évidemment les libs KDE pour des raisons évidentes. TiEmu les utilise pour pouvoir afficher les dialogues de fichiers KDE quand on est sous KDE (ou quand on le force dans la configuration) et pour la communication avec KTIGCC (serveur DCOP). TiEmu peut être compilé sans support KDE et KTIGCC (--without-kde), mais ne le sera jamais dans mes RPMs. Mais comme KDE est de toute façon nécessaire pour KTIGCC et que KTIGCC est de plus en plus un composant nécessaire de TIGCC (je considère le frontend en ligne de commande déprécié, un EDI (adapté à la situation, pas n'importe lequel!) est beaucoup plus commode), ben je ne vois pas le problème de demander KDE dans TiEmu aussi. De plus, TiEmu ne nécessite que kdelibs, c'est KTIGCC qui demande kdebase (pour la configuration proxy). Et de toute façon, il y a beaucoup d'autres logiciels utiles qui utilisent les kdelibs, donc je ne vois pas l'intérêt de virer les kdelibs à part de faire le lourd (ou le "léger" ).

Je ne comprends pas comment on puisse être prêt à utiliser des logiciels obsolètes en Xaw, Motif ou GTK+ 1.2 alors qu'il y a des alternatives KDE plus modernes, plus à jour, plus fonctionnelles et fournissant une meilleure intégration. C'est ridicule de dire que KDE est lourd, je le fais tourner sur un Pentium II 266 MHz avec 160 MO de RAM (mon PC portable).

> Enfin, pour TIGCC, le tarball binaire est censé être plus portable, mais ne l'est pas vraiment en réalité parce que glibc change beaucoup en ces derniers temps, donc il va être abandonné bientôt, il n'y aura plus que les sources et les RPMs
Hmm, arrêter de faire des packages binaires n'est pas exactement une bonne idée pour l'utilisabilité de TIGCC

Je ferai des paquetages binaires... pour Fedora, comme pour les autres logiciels que je package. Aux utilisateurs des autres distributions de packager TIGCC. Romain fait des paquetages Debian maintenant, par exemple.

Le problème avec les tarballs binaires est qu'ils sont en général dépendants d'une version glibc >= à la version avec laquelle ils ont été compilés. Or, aucune autre grande distribution ne distribue une glibc aussi à jour que Fedora, donc en pratique ça fait un tarball qui ne tourne que sous Fedora. (Tu t'en es bien rendu compte, sinon tu n'aurais pas refait un tarball pour une ancienne glibc. Tarball qui n'est déjà plus à jour, d'ailleurs, c'est le problème avec les paquetages tiers et pourquoi je ne les mets pas plus en avant qu'actuellement.) Quel intérêt par rapport au RPM? Quant à linker glibc statiquement, c'est explicitement déconseillé par les auteurs de glibc et ça peut entraîner d'autres problèmes (dépendance sur la version du noyau, par exemple).

Martial, c'est beau de taper sur Thibaut, mais ça aussi, c'est formulé de façon polémique, et ça fait un troll potentiel

Martial Demolins (./7) :
Donc tu te fous de ceux qui utilisent autre chose que KTIGCC?

Plus ou moins. Je considère les autres EDIs pas du tout appropriées pour TIGCC, aucune ne gère toutes les fonctionnalités de TIGCC. Quant à utiliser la ligne de commande directement, c'est beaucoup moins pratique que l'EDI.

Martial Demolins (./9) :
2. Je me réserve le droit de donner mon avis en tant qu'utilisateur quand même, de la même manière que j'essaie de faire autant de reports de bugs que je peux. Ce qui 'est dommage, c'est qu'il suffirait à Kevin de vouloir packager autrement pour arranger tout ça...

Packager autrement comment?
* KTIGCC ne peut évidemment pas être compilé sans KDE.
* TIGCC peut déjà être installé sans KTIGCC.
* Pour TiEmu, le choix d'activer ou non le support KDE est un choix au moment de la compilation, et désactiver le support KDE perdrait des fonctionnalités importantes (communication avec KTIGCC, dialogues de fichiers KDE), donc il est activé.

Oui, le RPM tigcc, dépendance de ktigcc, propose le compilateur en ligne de commande.
Cela dit, je ne conseille pas d'utiliser l'exécutable tigcc en ligne de commande, pour les raisons que je n'arrête pas de répéter (parce que cette question a été souvent posée récemment, je ne comprends pas cette mode de vouloir à tout prix utiliser autre chose que l'EDI qu'on propose): c'est le bordel avec les switches (alors que KTIGCC fait tout pour toi), pas d'intégration avec TiEmu (bouton Run) etc.

Martial Demolins (./11) :

Kevin Kofler (./10) :
* TIGCC peut déjà être installé sans KTIGCC.

attends alors... c'est moi qui déconne grave ou quoi?!? je peux compiler sans KDE sur ma machine? attends je vais vérifier, je suis complètement à l'ouest là...

TiEmu et TIGCC peuvent effectivement être installés/compilés sans KDE...

Oui, --without-kde sert à ça.

Kevin Kofler (./4) :
Les binaires fournis sont prévus pour Fedora 7 minimum (bientôt ce sera Fedora 8), donc c'est normal qu'ils ne tournent pas sur ton antiquité.

A la rigueur, un 'votre glibc est trop vieille. Allez vous rouler.' Mais là c'est une exception...
Sinon, tous les programmes que j'utilise (kernel, xorg, fluxbox, firefox, emacs, ...) sont à jour. Je ne te permets pas.

(Enfin, pour TIGCC, le tarball binaire est censé être plus portable, mais ne l'est pas vraiment en réalité parce que glibc change beaucoup en ces derniers temps, donc il va être abandonné bientôt, il n'y aura plus que les sources et les RPMs.)

Ce n'est pas le cas.

Kevin Kofler (./12) :
c'est le bordel avec les switches (alors que KTIGCC fait tout pour toi), pas d'intégration avec TiEmu (bouton Run) etc.

Mais il fait de l'asm, donc ca ne sert à rien.

Tu ne débogues jamais ton ASM? Ça marche toujours du premier coup?

Parce que ca marche pas pour charger un OS

Pas plus que pour le C, et tu peux utiliser les fonctionnalités de la fenêtre Disassembly qui sont plus stables que celles d'Insight (et tu as quand-même les noms de labels dans le désassemblage grace aux infos de débogage).

Kevin Kofler (./19) :
et tu as quand-même les noms de labels dans le désassemblage grace aux infos de débogage

ha oui ? c'est sympa, ça

Cela dit, les informations de débogage sont chargées par GDB, donc il n'y a pas ça dans la version sans GDB. (C'est pour une raison que la version sans GDB ne m'intéresse plus depuis longtemps. Toutes les fonctionnalités de débogage intéressantes utilisent GDB.)

Bon, comme j'ai un peu de temps là, j'ai regardé ce que ça donne. TI-89 HW1 AMS 2.09. Je fais "Debug file with TiEmu", je charge ton programme, j'envoie PreOs 1.0.4 (avec stdlib), je fais preos("install"), puis je lance ton programme. Le débogueur se charge comme prévu, mais j'ai un message "Make breakpoint pending on future shared library load?" Je dis "non", parce que le symbole qu'il cherche n'existe tout simplement pas (et même s'il était dans une lib, le débogueur n'aurait pas les infos de débogage pour la lib). Comme explication, il suffit de donner la sortie dans la console GDB:
Function "__main" not defined.
Comme tu n'as pas de code de démarrage, tu n'as pas de __main (c'est le nom interne de _main dans TIGCC, justement pour permettre le code de démarrage en kernel: _main est appelé comme ça pour la compatibilité antérieure, mais on ne veut pas en faire le _main kernel, on veut du code de démarrage, donc il y a un #define _main __main dans TIGCCLIB). Le débogueur est fait pour déboguer des programmes TIGCC, donc des programmes qui utilisent notre code de démarrage! Ensuite, j'ai l'habituel "Program received SIGTRAP, Trace/breakpoint trap", je dis OK, c'est le program entry breakpoint. Comme tu n'as pas de __main, je mets un breakpoint directement sur le _main kernel:

(gdb) break _main
Breakpoint 1 at 0x3c9d0: file main.s, line 34.

Je clique sur Continue... oups, ça ne breake pas (-> bogue). Regardant de plus près, le code en 0x3c9d0 n'est pas le code du début de _main, donc il y a un problème dans les informations de débogage. Si tu as eu des plantages au chargement des informations de débogage, c'est probablement le même bogue.

Je confirme que c'est un bogue de la chaîne d'outils (TIGCC ou TiEmu).

C'est bon, j'ai compris ce qui se passe! C'est un bogue dans TiEmu. En fait, il est impossible de déboguer des programmes kernel depuis le 15 juillet 2005 (donc essentiellement depuis que le tigcc-debugging-branch existe), ça montre à quel point le mode kernel est utilisé.

J'explique: ce que fait TiEmu quand on fait "Debug file with TiEmu" est:
1. il envoie le programme,
2. il met un program entry breakpoint dessus.
3. il attend que tu lances le programme avec les bons arguments.
Une fois le programme lancé:
4. le program entry breakpoint est activé,
5. TiEmu supprime le program entry breakpoint,
6. TiEmu charge les informations de débogage à l'adresse du program entry breakpoint.
Et voilà où se trouve le problème. En effet, mon commit du 15 juillet 2005 a modifié les program entry breakpoints pour s'activer sur le début de _main en kernel. Par conséquent, l'adresse du program entry breakpoint est celle de _main, pas celle de __ld_entry_point, donc pas la bonne adresse pour reloger les informations de débogage. Il faut que je retranche l'offset quand je charge le program entry breakpoint.

Je vais corriger ça, mais je me demande s'il vaut le coup de supporter le débogage de programmes kernel étant donné que tu es visiblement le seul à l'utiliser...

Kevin Kofler (./24) :
ça montre à quel point le mode kernel est utilisé.

Ca montre surtout à quel point ton debuggueur est utilisé.

Martial : Oooohhh c'est mimi

> ça montre à quel point le mode kernel est utilisé.
> Ca montre surtout à quel point ton debuggueur est utilisé.
Je pense que vous avez raison tous les deux, en fait

Ca fait longtemps que la majorité des nouveaux programmes est développée en mode AMS native; on sait très bien que plusieurs développeurs de kernel-based ici présents n'aiment pas TIEmu pour plusieurs raisons, et l'utilisent moins que VTI.

Je vais corriger ça, mais je me demande s'il vaut le coup de supporter le débogage de programmes kernel étant donné que tu es visiblement le seul à l'utiliser...

Je pense qu'il serait intéressant de supporter les deux. Cela ferait de TiEmu un outil vraiment complet... Mais cela n'engage que moi, je ne veux pas déclencher de polémique trollistique ;-)

(Je l'aurais bien utilisé, mais par un concours de circonstances, tigcc n'arrivant pas à compiler mes sources qui compilaient parfaitement il y a deux ans, ça m'a soûlé et j'ai laissé tomber. Si l'envie me reprend de retenter le coup je ferais peut-ête un bug report ou je viendrais en parler, mais ça risque de prendre un certain temps...)