[HS]backtrace amd64

Le
François Boisson
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'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
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
Basile Starynkevitch
Le #23366111
On Sun, 15 May 2011 22:58:30 +0200
François Boisson
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 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 #23366261
Le Mon, 16 May 2011 07:03:00 +0200
Basile Starynkevitch
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 #23368681
Le Mon, 16 May 2011 08:20:38 +0200
François Boisson
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
Le #23368781
On Mon, 16 May 2011 22:23:59 +0200
François Boisson
Le Mon, 16 May 2011 08:20:38 +0200
François Boisson
> 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 #23369321
Le Mon, 16 May 2011 22:52:28 +0200
Basile Starynkevitch
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 à

unwind_backtrace = __libc_dlsym (libgcc_handle, "_Unwind_Backtrace");
unwind_getip = __libc_dlsym (libgcc_handle, "_Unwind_GetIP");

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/
Publicité
Poster une réponse
Anonyme