La fonction ci dessous m'a permis de remonter les adresses des fonctions
appelantes dans un programme C (en gros, la pile contient à chaque fois le
registre ebp et l'adresse de retour, et le registre ebp contient l'adresse du
«ebp» de l'appel précédent. J'ignore si il existe une méthode plus efficace et
si c'est celle utilisé par gdb dans le backtrace. Par contre, pour un
programme 64 bits, cette méthode ne fonctionne plus,
Quelqu'un voit-il une méthode pour faire cela?
(Je sais c'est HS mais peut être certains seront intéressés, j'ai regardé les
sources de gdb pour voir leur méthode mais c'est décourageant...)
long int get_pile(int n)
{
long unsigned int *pile;
long unsigned int *oldpile;
asm("movl %%ebp,%0" : "=l" (pile));
for (;(n>0) && (pile != 0);n--) {
oldpile=*((long int *) (pile));
pile = oldpile;
}
if (pile != 0)
return(*((long int *) (pile +1)));
else return(0);
}
pile(n) renvoit l'adresse du nième «parent» de la fonction.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110515225830.070288b7.user.anti-spam@maison.homelinux.net
On Sun, 15 May 2011 22:58:30 +0200 François Boisson wrote:
Bonjour
La fonction ci dessous m'a permis de remonter les adresses des fonctions appelantes dans un programme C (en gros, la pile contient à chaque fois le registre ebp et l'adresse de retour, et le registre ebp contient l'adress e du «ebp» de l'appel précédent.
Il existe une fonction backtrace (avec #include <execinfo.h>) dans la Glibc qui fait le boulot. Attention, c'est une extension GNU qui n'existe pas partout!!! (par exemple, probablement pas sous un FreeBSD).
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais plusieurs cas où en aurait envie). Si le code C que chasse François est généré, il peut être plus simple de modifier le générateur... ( je fais des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On Sun, 15 May 2011 22:58:30 +0200
François Boisson <user.anti-spam@maison.homelinux.net> wrote:
Bonjour
La fonction ci dessous m'a permis de remonter les adresses des fonctions
appelantes dans un programme C (en gros, la pile contient à chaque fois le
registre ebp et l'adresse de retour, et le registre ebp contient l'adress e du
«ebp» de l'appel précédent.
Il existe une fonction backtrace (avec #include <execinfo.h>) dans la
Glibc qui fait le boulot. Attention, c'est une extension GNU qui
n'existe pas partout!!! (par exemple, probablement pas sous un FreeBSD).
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais
plusieurs cas où en aurait envie). Si le code C que chasse François est
généré, il peut être plus simple de modifier le générateur... ( je fais
des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110516070300.66e1bf9f.basile@starynkevitch.net
On Sun, 15 May 2011 22:58:30 +0200 François Boisson wrote:
Bonjour
La fonction ci dessous m'a permis de remonter les adresses des fonctions appelantes dans un programme C (en gros, la pile contient à chaque fois le registre ebp et l'adresse de retour, et le registre ebp contient l'adress e du «ebp» de l'appel précédent.
Il existe une fonction backtrace (avec #include <execinfo.h>) dans la Glibc qui fait le boulot. Attention, c'est une extension GNU qui n'existe pas partout!!! (par exemple, probablement pas sous un FreeBSD).
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais plusieurs cas où en aurait envie). Si le code C que chasse François est généré, il peut être plus simple de modifier le générateur... ( je fais des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
François Boisson
Le Mon, 16 May 2011 07:03:00 +0200 Basile Starynkevitch a écrit:
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais plusieurs cas où en aurait envie). Si le code C que chasse François est généré, il peut être plus simple de modifier le générateur... (je fais des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Réponse et illustration à une question d'un élève sur la compilation, question qui m'a fait prendre conscience de la différence majeure entre le code 32 bits et le 64 bits, alors que le code 16 bits et le 32 bits sont assez analogues. Que l'élève profite de ces indications pour aller déplomber 3-4 logiciels est une possibilité, j'ai aussi certainement des anciens élèves qui ont profité des maths que je leur ai enseigné pour mettre au point des stratégies permettant d'amplifier la spéculation et les effets des crises ou de virer des gens dans des entreprises, d'autres ont fait des choses plus agréables. Si on se met à se poser des questions sur chaque usage des réponses aux questions posées, on arrête d'être prof.
Merci de la réponse, je vais éplucher le code de backtrace.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le Mon, 16 May 2011 07:03:00 +0200
Basile Starynkevitch <basile@starynkevitch.net> a écrit:
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais
plusieurs cas où en aurait envie). Si le code C que chasse François est
généré, il peut être plus simple de modifier le générateur... (je fais
des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Réponse et illustration à une question d'un élève sur la compilation, question
qui m'a fait prendre conscience de la différence majeure entre le code 32 bits
et le 64 bits, alors que le code 16 bits et le 32 bits sont assez analogues.
Que l'élève profite de ces indications pour aller déplomber 3-4 logiciels
est une possibilité, j'ai aussi certainement des anciens élèves qui
ont profité des maths que je leur ai enseigné pour mettre au point des
stratégies permettant d'amplifier la spéculation et les effets des crises ou
de virer des gens dans des entreprises, d'autres ont fait des choses plus
agréables. Si on se met à se poser des questions sur chaque usage des réponses
aux questions posées, on arrête d'être prof.
Merci de la réponse, je vais éplucher le code de backtrace.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110516082038.ebe5ad58.user.anti-spam@maison.homelinux.net
Le Mon, 16 May 2011 07:03:00 +0200 Basile Starynkevitch a écrit:
Mais j'aimerais comprendre pourquoi François a besoin de ça (je connais plusieurs cas où en aurait envie). Si le code C que chasse François est généré, il peut être plus simple de modifier le générateur... (je fais des choses comme ça dans GCC MELT voir gcc-melt.org ...)
Réponse et illustration à une question d'un élève sur la compilation, question qui m'a fait prendre conscience de la différence majeure entre le code 32 bits et le 64 bits, alors que le code 16 bits et le 32 bits sont assez analogues. Que l'élève profite de ces indications pour aller déplomber 3-4 logiciels est une possibilité, j'ai aussi certainement des anciens élèves qui ont profité des maths que je leur ai enseigné pour mettre au point des stratégies permettant d'amplifier la spéculation et les effets des crises ou de virer des gens dans des entreprises, d'autres ont fait des choses plus agréables. Si on se met à se poser des questions sur chaque usage des réponses aux questions posées, on arrête d'être prof.
Merci de la réponse, je vais éplucher le code de backtrace.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
François Boisson
Le Mon, 16 May 2011 08:20:38 +0200 François Boisson a écrit:
Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c ), le majorité du travail semble être fait par la fonction uw_frame_state_for mais le code est assez hermétique.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le Mon, 16 May 2011 08:20:38 +0200
François Boisson <user.anti-spam@maison.homelinux.net> a écrit:
Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir
gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c ), le
majorité du travail semble être fait par la fonction uw_frame_state_for mais
le code est assez hermétique.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110516222359.fa3a7dcb.user.anti-spam@maison.homelinux.net
Le Mon, 16 May 2011 08:20:38 +0200 François Boisson a écrit:
Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c ), le majorité du travail semble être fait par la fonction uw_frame_state_for mais le code est assez hermétique.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Basile Starynkevitch
On Mon, 16 May 2011 22:23:59 +0200 François Boisson wrote:
Le Mon, 16 May 2011 08:20:38 +0200 François Boisson a écrit:
> Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c )
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc, car la fonction backtrace est dans la Glibc et elle marche même pour du code compilé par autre chose que gcc (par exemple tinycc ou clang). Par contre, certaines optimisations du compilateur (par exemple -fomit-frame-pointer ou bien l'optimisation des appels récursifs terminaux) suppriment la génération du code et de l'information nécessaires au fonctionnement de la fonction backtrace.
La fonction backtrace est dépendante du processeur (et aussi des optimisations du compilateur). http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/backtrac e.c;hÏ3b2719b9e95fef1dc237e8e6429a81581294af;hb=HEAD pour le i386 (32 bits) et http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ia64/backtrac e.c;hÔff29102261505da02e785433197c0518cd110b;hb=HEAD pour le Itanium ia64 et le AMD x86-64 (64 bits). Bizarrement, l'agencement des cadres de pile est suffisamment proche sur ces deux processeurs très différents pour qu'ils puissent partager le code de backtrace
Voir aussi http://www.nongnu.org/libunwind/
En gros, la fonction backtrace est rarement utilisée, et elle ne marche pas si bien que ça en pratique (en particulier, sa fonction soeur backtrace_symbols imprime désagréablement les addresses des fonctions actives). Certains programmes (peut-être l'interprète python) fork() un gdb sur le processur courant pour avoir l'équivalent.
Par contre, certains programmes introspectifs gagnent à l'utiliser. Le lecteur curieux pourrait par exemple se reporter au livre Artificial Beings de Jacques Pitrat http://www.iste.co.uk/index.php?f=a&ACTION=View&id%7 (et notamment l'annexe). Il se trouve que le système CAIA de Pitrat n'utilise pas la fonction backtrace, mais a ses propres piles, notamment pour avoir un fonctionnement plus sûr et plus portable de la fonctionalité de backtrace.
Java fournit la classe CallStack, voir par exemple http://www.seas.upenn.edu/~sweirich/tdj/tutorial/Example9_CallStackIntrospe ction.htm
Scheme a bien évidemment ses continuations (call/cc) mais c'est moins introspectif.
En se fatiguant, on peut coder un traiteur de signal (machine dépendant) qui fait des choses similaires.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On Mon, 16 May 2011 22:23:59 +0200
François Boisson <user.anti-spam@maison.homelinux.net> wrote:
Le Mon, 16 May 2011 08:20:38 +0200
François Boisson <user.anti-spam@maison.homelinux.net> a écrit:
> Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir
gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c )
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc,
car la fonction backtrace est dans la Glibc et elle marche même pour du
code compilé par autre chose que gcc (par exemple tinycc ou clang). Par
contre, certaines optimisations du compilateur (par exemple
-fomit-frame-pointer ou bien l'optimisation des appels récursifs
terminaux) suppriment la génération du code et de l'information
nécessaires au fonctionnement de la fonction backtrace.
La fonction backtrace est dépendante du processeur (et aussi des
optimisations du compilateur).
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/backtrac e.c;h=cf3b2719b9e95fef1dc237e8e6429a81581294af;hb=HEAD
pour le i386 (32 bits) et
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ia64/backtrac e.c;h=d4ff29102261505da02e785433197c0518cd110b;hb=HEAD
pour le Itanium ia64 et le AMD x86-64 (64 bits). Bizarrement,
l'agencement des cadres de pile est suffisamment proche sur ces deux
processeurs très différents pour qu'ils puissent partager le code de
backtrace
Voir aussi http://www.nongnu.org/libunwind/
En gros, la fonction backtrace est rarement utilisée, et elle ne marche
pas si bien que ça en pratique (en particulier, sa fonction soeur
backtrace_symbols imprime désagréablement les addresses des fonctions
actives). Certains programmes (peut-être l'interprète python) fork() un
gdb sur le processur courant pour avoir l'équivalent.
Par contre, certains programmes introspectifs gagnent à l'utiliser. Le
lecteur curieux pourrait par exemple se reporter au livre Artificial
Beings de Jacques Pitrat
http://www.iste.co.uk/index.php?f=a&ACTION=View&id=257 (et notamment
l'annexe). Il se trouve que le système CAIA de Pitrat n'utilise pas la
fonction backtrace, mais a ses propres piles, notamment pour avoir un
fonctionnement plus sûr et plus portable de la fonctionalité de
backtrace.
Java fournit la classe CallStack, voir par exemple
http://www.seas.upenn.edu/~sweirich/tdj/tutorial/Example9_CallStackIntrospe ction.htm
Scheme a bien évidemment ses continuations (call/cc) mais c'est moins
introspectif.
En se fatiguant, on peut coder un traiteur de signal (machine
dépendant) qui fait des choses similaires.
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110516225228.a86de88d.basile@starynkevitch.net
On Mon, 16 May 2011 22:23:59 +0200 François Boisson wrote:
Le Mon, 16 May 2011 08:20:38 +0200 François Boisson a écrit:
> Merci de la réponse, je vais éplucher le code de backtrace.
Pour info, le code est dans les sources de gcc (voir gcc-4.4.5/gcc/unwind.inc etgcc-4.4.5/gcc/config/ia64/unwind-ia64.c )
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc, car la fonction backtrace est dans la Glibc et elle marche même pour du code compilé par autre chose que gcc (par exemple tinycc ou clang). Par contre, certaines optimisations du compilateur (par exemple -fomit-frame-pointer ou bien l'optimisation des appels récursifs terminaux) suppriment la génération du code et de l'information nécessaires au fonctionnement de la fonction backtrace.
La fonction backtrace est dépendante du processeur (et aussi des optimisations du compilateur). http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/backtrac e.c;hÏ3b2719b9e95fef1dc237e8e6429a81581294af;hb=HEAD pour le i386 (32 bits) et http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ia64/backtrac e.c;hÔff29102261505da02e785433197c0518cd110b;hb=HEAD pour le Itanium ia64 et le AMD x86-64 (64 bits). Bizarrement, l'agencement des cadres de pile est suffisamment proche sur ces deux processeurs très différents pour qu'ils puissent partager le code de backtrace
Voir aussi http://www.nongnu.org/libunwind/
En gros, la fonction backtrace est rarement utilisée, et elle ne marche pas si bien que ça en pratique (en particulier, sa fonction soeur backtrace_symbols imprime désagréablement les addresses des fonctions actives). Certains programmes (peut-être l'interprète python) fork() un gdb sur le processur courant pour avoir l'équivalent.
Par contre, certains programmes introspectifs gagnent à l'utiliser. Le lecteur curieux pourrait par exemple se reporter au livre Artificial Beings de Jacques Pitrat http://www.iste.co.uk/index.php?f=a&ACTION=View&id%7 (et notamment l'annexe). Il se trouve que le système CAIA de Pitrat n'utilise pas la fonction backtrace, mais a ses propres piles, notamment pour avoir un fonctionnement plus sûr et plus portable de la fonctionalité de backtrace.
Java fournit la classe CallStack, voir par exemple http://www.seas.upenn.edu/~sweirich/tdj/tutorial/Example9_CallStackIntrospe ction.htm
Scheme a bien évidemment ses continuations (call/cc) mais c'est moins introspectif.
En se fatiguant, on peut coder un traiteur de signal (machine dépendant) qui fait des choses similaires.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
François Boisson
Le Mon, 16 May 2011 22:52:28 +0200 Basile Starynkevitch a écrit:
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc, car la fonction backtrace est dans la Glibc et elle marche même pour du code compilé par autre chose que gcc (par exemple tinycc ou clang). Par contre, certaines optimisations du compilateur (par exemple -fomit-frame-pointer ou bien l'optimisation des appels récursifs terminaux) suppriment la génération du code et de l'information nécessaires au fonctionnement de la fonction backtrace.
Effectivement, je ne l'ai pas écrit mais le code dans la libc se résume à
qui m'a conduit aux sources de gcc et aux fichiers cités dans mon précédent message. Je vais regarder les liens, merci
François Boisson,
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le Mon, 16 May 2011 22:52:28 +0200
Basile Starynkevitch <basile@starynkevitch.net> a écrit:
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc,
car la fonction backtrace est dans la Glibc et elle marche même pour du
code compilé par autre chose que gcc (par exemple tinycc ou clang). Par
contre, certaines optimisations du compilateur (par exemple
-fomit-frame-pointer ou bien l'optimisation des appels récursifs
terminaux) suppriment la génération du code et de l'information
nécessaires au fonctionnement de la fonction backtrace.
Effectivement, je ne l'ai pas écrit mais le code dans la libc se résume à
qui m'a conduit aux sources de gcc et aux fichiers cités dans mon précédent
message.
Je vais regarder les liens, merci
François Boisson,
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110517074512.fbe8c814.user.anti-spam@maison.homelinux.net
Le Mon, 16 May 2011 22:52:28 +0200 Basile Starynkevitch a écrit:
Ca m'étonnerait que ce soit le code de backtrace fournie par la glibc, car la fonction backtrace est dans la Glibc et elle marche même pour du code compilé par autre chose que gcc (par exemple tinycc ou clang). Par contre, certaines optimisations du compilateur (par exemple -fomit-frame-pointer ou bien l'optimisation des appels récursifs terminaux) suppriment la génération du code et de l'information nécessaires au fonctionnement de la fonction backtrace.
Effectivement, je ne l'ai pas écrit mais le code dans la libc se résume à
