Pardonnez-moi si je suis à la limite du hors charte et redirigez-moi
si nécessaire... J'essaye de débugguer un programme assez gros et
multithreadé. Je croyais avoir achevé l'opération mais j'ai un tas de
problèmes sous Solaris Sparc en version 64 bits (pour le userland).
Je m'explique :
1/ j'ai développé un truc qui utilise les appels systèmes de la
libpthread sur les OS suivants : Solaris 10 (i86pc), Solaris 9 (sparc),
NetBSD 4.0 (sparc), Linux (amd64), FreeBSD 7.0 (i386) Solaris 10
(sun4v).
2/ le programme lance un tas de threads (une grosse centaine).
Dans _tous_ les cas sauf un, il fonctionne parfaitement plusieurs
centaines d'heures CPU sans aucun problème. Le souci a lieu avec Solaris
10 sur processeur T1. Si je compile le code en 32 bits, aucun problème.
Maintenant, si je recompile le tout en 64 bits (j'en ai besoin pour des
histoires de volume de données), j'ai un thread de temps en temps qui
part dans la nature et qui bloque les calculs. J'oubliais de dire que le
programme en question est compilé avec gcc. Cela se produit
systématiquement. Ce n'est pas un problème de type de données car les
types utilisés sont tous définis par des typedef pour éviter les
problèmes de portabilité triviaux. Je ne pense pas que le problème
provienne non plus de Solaris...
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb
qu'il doit utiliser un programme au format elf64 (visiblement, le format
64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque). mdb est parfaitement
incompréhensible malgré sa doc (qui n'est d'ailleurs pas à jour) et j'essaye
d'en sortir quelque chose depuis une grosse semaine sans aucun résultat.
La machine en question étant déportée, je ne peux pas utiliser de
grosses applications graphiques (ddd est tout juste utilisable), mais ce
n'est pas un problème, j'ai l'habitude d'utiliser des outils en ligne de
commande pour peu qu'ils soient 'utilisables'.
La question est donc simple. Qu'utilisez-vous pour débugguer un
programme écrit en C sous Solaris dès que celui-ci est compilé pour
fonctionner dans le userland 64 bits ?
Merci de vos lumières,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc
JKB wrote:
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb qu'il doit utiliser un programme au format elf64 (visiblement, le format 64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La compatibilité avec gcc évolue régulièrement (essayer une version "express" peut être valable). Aussi, si c'est du C, ne serait-il pas possible de recompiler avec suncc pour augmenter les chances ?
La machine en question étant déportée, je ne peux pas utiliser de grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais plutôt peur des limitations liées au processeur du T1000.
Studio vient aussi avec des outils de détection des race conditions et deadlocks, ça peut s'essayer.
JKB wrote:
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb
qu'il doit utiliser un programme au format elf64 (visiblement, le format
64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La
compatibilité avec gcc évolue régulièrement (essayer une version
"express" peut être valable). Aussi, si c'est du C, ne serait-il pas
possible de recompiler avec suncc pour augmenter les chances ?
La machine en question étant déportée, je ne peux pas utiliser de
grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais
plutôt peur des limitations liées au processeur du T1000.
Studio vient aussi avec des outils de détection des race conditions et
deadlocks, ça peut s'essayer.
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb qu'il doit utiliser un programme au format elf64 (visiblement, le format 64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La compatibilité avec gcc évolue régulièrement (essayer une version "express" peut être valable). Aussi, si c'est du C, ne serait-il pas possible de recompiler avec suncc pour augmenter les chances ?
La machine en question étant déportée, je ne peux pas utiliser de grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais plutôt peur des limitations liées au processeur du T1000.
Studio vient aussi avec des outils de détection des race conditions et deadlocks, ça peut s'essayer.
JKB
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb qu'il doit utiliser un programme au format elf64 (visiblement, le format 64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10". Setting up the environment for debugging gdb. ... tchaikovski:[~/src/gdb-6.8/gdb] > file gdb gdb: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/src/gdb-6.8/gdb] >
Le gdb en question est parfaitement capable d'utiliser les codes SPARCV8+. Par contre, en SPARCV9, j'obtiens :
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb /usr/shared-apps/bin/rpl GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... I'm sorry, Dave, I can't do that. Symbol format `elf64-sparc' unknown. Setting up the environment for debugging gdb.
Je n'arrive donc à rien...
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La
C'est la dernière version avec les derniers patches. Je m'en suis assuré.
compatibilité avec gcc évolue régulièrement (essayer une version "express" peut être valable). Aussi, si c'est du C, ne serait-il pas possible de recompiler avec suncc pour augmenter les chances ?
J'aimerais ne pas en arriver là (pour d'obscures raisons, je n'arrive à lier correctement le code qu'avec GNU-ld. J'ai un problème dans la compilation 64 bits entre un bout de code écrit en Fortran90... Je n'ai pas creusé plus pour l'instant, tout ce que je sais, c'est que le compilo Fortran n'aime pas le linker de Solaris dès qu'on lui cause 64 bits...).
La machine en question étant déportée, je ne peux pas utiliser de grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais plutôt peur des limitations liées au processeur du T1000.
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement, donc pour des applications massivement parallèles. Une T1000 à 1 GHz explose littéralement un serveur Xeon à huit voies (et je compte m'amuser prochainement avec un T2+ à 128 voies ;-) ). Maintenant, il est vrai que pour des applications qui n'utilisent pas les spécificités de ce processeur sont un peu "à la ramasse" sur une T1000.
Studio vient aussi avec des outils de détection des race conditions et deadlocks, ça peut s'essayer.
Ouaips, on va essayer aussi...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 06-03-2009, ? propos de
Re: [HS?] Debugger Solaris Sparc (64 bits),
Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb
qu'il doit utiliser un programme au format elf64 (visiblement, le format
64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
Setting up the environment for debugging gdb.
...
tchaikovski:[~/src/gdb-6.8/gdb] > file gdb
gdb: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens
dynamiques, fichier intégral
tchaikovski:[~/src/gdb-6.8/gdb] >
Le gdb en question est parfaitement capable d'utiliser les codes
SPARCV8+. Par contre, en SPARCV9, j'obtiens :
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb /usr/shared-apps/bin/rpl
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
I'm sorry, Dave, I can't do that. Symbol format `elf64-sparc' unknown.
Setting up the environment for debugging gdb.
Je n'arrive donc à rien...
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La
C'est la dernière version avec les derniers patches. Je m'en suis
assuré.
compatibilité avec gcc évolue régulièrement (essayer une version
"express" peut être valable). Aussi, si c'est du C, ne serait-il pas
possible de recompiler avec suncc pour augmenter les chances ?
J'aimerais ne pas en arriver là (pour d'obscures raisons, je
n'arrive à lier correctement le code qu'avec GNU-ld. J'ai un problème
dans la compilation 64 bits entre un bout de code écrit en Fortran90...
Je n'ai pas creusé plus pour l'instant, tout ce que je sais, c'est que
le compilo Fortran n'aime pas le linker de Solaris dès qu'on lui cause
64 bits...).
La machine en question étant déportée, je ne peux pas utiliser de
grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais
plutôt peur des limitations liées au processeur du T1000.
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
donc pour des applications massivement parallèles. Une T1000 à 1 GHz
explose littéralement un serveur Xeon à huit voies (et je compte
m'amuser prochainement avec un T2+ à 128 voies ;-) ). Maintenant, il est
vrai que pour des applications qui n'utilisent pas les spécificités de
ce processeur sont un peu "à la ramasse" sur une T1000.
Studio vient aussi avec des outils de détection des race conditions et
deadlocks, ça peut s'essayer.
Ouaips, on va essayer aussi...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
J'essaye de débugguer. Je n'ai pas réussi à faire comprendre à gdb qu'il doit utiliser un programme au format elf64 (visiblement, le format 64 bits n'est pas supporté en architecture sparc sous Solaris par gdb).
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10". Setting up the environment for debugging gdb. ... tchaikovski:[~/src/gdb-6.8/gdb] > file gdb gdb: ELF 64 bits MSB exécutable SPARCV9 Version 1, avec liens dynamiques, fichier intégral tchaikovski:[~/src/gdb-6.8/gdb] >
Le gdb en question est parfaitement capable d'utiliser les codes SPARCV8+. Par contre, en SPARCV9, j'obtiens :
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb /usr/shared-apps/bin/rpl GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"... I'm sorry, Dave, I can't do that. Symbol format `elf64-sparc' unknown. Setting up the environment for debugging gdb.
Je n'arrive donc à rien...
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
Là encore est-ce la dernière version avec les derniers patchs ? La
C'est la dernière version avec les derniers patches. Je m'en suis assuré.
compatibilité avec gcc évolue régulièrement (essayer une version "express" peut être valable). Aussi, si c'est du C, ne serait-il pas possible de recompiler avec suncc pour augmenter les chances ?
J'aimerais ne pas en arriver là (pour d'obscures raisons, je n'arrive à lier correctement le code qu'avec GNU-ld. J'ai un problème dans la compilation 64 bits entre un bout de code écrit en Fortran90... Je n'ai pas creusé plus pour l'instant, tout ce que je sais, c'est que le compilo Fortran n'aime pas le linker de Solaris dès qu'on lui cause 64 bits...).
La machine en question étant déportée, je ne peux pas utiliser de grosses applications graphiques (ddd est tout juste utilisable),
Pour l'aspect graphique, NX (de nomachine) fonctionne très bien. J'aurais plutôt peur des limitations liées au processeur du T1000.
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement, donc pour des applications massivement parallèles. Une T1000 à 1 GHz explose littéralement un serveur Xeon à huit voies (et je compte m'amuser prochainement avec un T2+ à 128 voies ;-) ). Maintenant, il est vrai que pour des applications qui n'utilisent pas les spécificités de ce processeur sont un peu "à la ramasse" sur une T1000.
Studio vient aussi avec des outils de détection des race conditions et deadlocks, ça peut s'essayer.
Ouaips, on va essayer aussi...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Marc
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb
GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec
6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque
chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette
utilisation correcte :-(
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
JKB
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
Ah ? Je n'avais rien trouvé sur Google. Je vais essayer de ce pas.
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
Nous sommes bien d'accord (et ça a été fait).
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
C'est peut-être pour ça que les T1000 sont livrées d'origine sans carte graphique. De toute façon, vu le boucan de la machine, je préfère de loin avoir cette machine loin de mon bureau ;-)
Merci pour tout,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 06-03-2009, ? propos de
Re: [HS?] Debugger Solaris Sparc (64 bits),
Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb
GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec
6.6 (voire une version encore plus vieille).
Ah ? Je n'avais rien trouvé sur Google. Je vais essayer de ce pas.
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque
chose d'anormal...
Nous sommes bien d'accord (et ça a été fait).
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette
utilisation correcte :-(
C'est peut-être pour ça que les T1000 sont livrées d'origine sans
carte graphique. De toute façon, vu le boucan de la machine, je préfère
de loin avoir cette machine loin de mon bureau ;-)
Merci pour tout,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
Ah ? Je n'avais rien trouvé sur Google. Je vais essayer de ce pas.
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
Nous sommes bien d'accord (et ça a été fait).
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
C'est peut-être pour ça que les T1000 sont livrées d'origine sans carte graphique. De toute façon, vu le boucan de la machine, je préfère de loin avoir cette machine loin de mon bureau ;-)
Merci pour tout,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 06-03-2009, ? propos de
Re: [HS?] Debugger Solaris Sparc (64 bits),
Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb
GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec
6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est
incapable de me fournir une quelconque indication (il n'arrive pas à
remonter dans la pile, donc je n'arrive ni à changer de thread, ni à
savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque
chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette
utilisation correcte :-(
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 06-03-2009, ? propos de Re: [HS?] Debugger Solaris Sparc (64 bits), Marc ?crivait dans fr.comp.lang.c :
JKB wrote:
C'est un gdb récent compilé en 64 bits ?
Oui.
tchaikovski:[~/src/gdb-6.8/gdb] > ./gdb GNU gdb 6.8
Peut-être avec un plus ancien ? Google semble favorable à un essai avec 6.6 (voire une version encore plus vieille).
DBX me fait un segfault au lancement en 32 bits et en 64 bits est incapable de me fournir une quelconque indication (il n'arrive pas à remonter dans la pile, donc je n'arrive ni à changer de thread, ni à savoir à quel endroit le thread bloque).
J'espère que vous avez fait remonter à Sun, il y a quand même quelque chose d'anormal...
J'avoue que j'aime assez le T1 dès qu'on l'utilise correctement,
Moi aussi, mais peu d'applications graphiques entrent dans cette utilisation correcte :-(
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.