Le 8 mars 2017 à 11:44, François TOURDE <fra-duf-no-s...@tourde.org> a écrit :
> Bonjour, > > Le 17233ième jour après Epoch, > Olivier écrivait: > > > Pardonnez-moi si mes questions semblent idiotes mais: > > Pas de questions idiotes, seules les réponsent peuvent l'être :-p > > Pardonne moi, donc, si mes réponses sont idiotes... > > > 1. À quoi sert exactement un paquet <paquet>-dbgsym ? Doit-on installer > > <paquet> et <paquet>-dbgsym ou <paquet>-dbgsym à la place de <paquet> > > ? > > C'est un paquet qui va contenir des infos de débug, des symboles > donc. Le paquet s'installe à la place de l'autre, et contient des > binaires un peu (voire beaucoup) plus gros, à cause des infos de debug. > > En général, les programmes sont compilés avec et sans les infos de > débug, ou alors juste avec puis sont "strippés" (man strip). Cela donne > deux versions des objets, l'un avec et l'autre sans les infos de debug. > > > 2. Quel rapport entre <paquet>-dbgsym et la production de fichier > > coredump ? > > Avec la production du coredump, rien, mais par contre pour l'analyse de > ce coredump, avoir les infos de débug est utile. Tu peux voir le nom des > variables en clair plutôt que les adresses hexa, tu vois la pile sous > forme de nom de fonctions et non sous forme d'adresses... > > > 3. Plus généralement, dans mon imaginaire "un fichier coredump est la > > condition nécessaire et suffisante pour qu'un développeur (ie pas un > > mainteneur) puisse analyser un plantage". Est-ce plutôt exact sinon > qu'est > > ce qui le serait d'avantage ? > > Ce n'est ni nécessaire, ni suffisant, mais ça peut être super pratique. > > Le coredump (illustré des infos de debug) est un instantané pris au > moment du plantage, avec lequel tu peux voir les variables, la pile, > etc... Mais tu ne vois pas par exemple les conditions initiales, le > chemin du programme pour en arriver là, etc... > > J'espère avoir éclairé un peu ta lanterne. > Parfaitement ! > > -- > Do not sleep in a eucalyptus tree tonight. > >
