[HS?] Debugger Solaris Sparc (64 bits)

Le
JKB
Bonjour à tous,

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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Marc
Le #18833881
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
Le #18834801
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 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 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
Le #18835101
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
Le #18835091
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 #18843651
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.
Publicité
Poster une réponse
Anonyme