Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
> Que représente le premier champ en début de ligne dans le fichier maps?
>
> Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
> priori ceci ne correspond pas à des adresses réelles en mémoire
> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
> pris pour la pile (stack) du processus), ce qui est bien au délà du giga
> dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
> me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
> Que représente le premier champ en début de ligne dans le fichier maps?
>
> Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
> priori ceci ne correspond pas à des adresses réelles en mémoire
> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
> pris pour la pile (stack) du processus), ce qui est bien au délà du giga
> dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
> me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
> Que représente le premier champ en début de ligne dans le fichier maps?
>
> Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
> priori ceci ne correspond pas à des adresses réelles en mémoire
> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
> pris pour la pile (stack) du processus), ce qui est bien au délà du giga
> dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
> me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
Si tu regarde plus en détail, tu verras que _tous_ les
processus utilisent plus ou moins les même adresses, car ils
marchent tous de la même façon. Donc, chaque
processus a son code en 0x08048000, ses variables ensuite,
et ainsi de suite, et la magie de la vm de Linux replace ça
quelque part dans l'ordinateur (peut-être en RAM, peut-être
sur disque dans le swap), et le processus n'a même pas de
moyen de savoir où se trouvent physiquement ses données.Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est définit au moment du link dans ld. En adresses
virtuelle, ça par de 0xc0000000 et ça va en descendant, en
général suffisament loin (à vue de nez, environ 7Mo sur mon
système, ça peut peut-être se régler, mais je ne pense pas
que qui que ce soit en ai déjà eu besoin :-)C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
J'ai une question en retour: pourquoi est-ce important? A
priori, ça ne devrait intéresser que ceux qui bidouillent le
compilateur, ou la partie vm du noyau.
Y.
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
Si tu regarde plus en détail, tu verras que _tous_ les
processus utilisent plus ou moins les même adresses, car ils
marchent tous de la même façon. Donc, chaque
processus a son code en 0x08048000, ses variables ensuite,
et ainsi de suite, et la magie de la vm de Linux replace ça
quelque part dans l'ordinateur (peut-être en RAM, peut-être
sur disque dans le swap), et le processus n'a même pas de
moyen de savoir où se trouvent physiquement ses données.
Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est définit au moment du link dans ld. En adresses
virtuelle, ça par de 0xc0000000 et ça va en descendant, en
général suffisament loin (à vue de nez, environ 7Mo sur mon
système, ça peut peut-être se régler, mais je ne pense pas
que qui que ce soit en ai déjà eu besoin :-)
C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
J'ai une question en retour: pourquoi est-ce important? A
priori, ça ne devrait intéresser que ceux qui bidouillent le
compilateur, ou la partie vm du noyau.
Y.
On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:Que représente le premier champ en début de ligne dans le fichier maps?
Dans le man il est écrit que c'est "l'espace d'adressage du processus". A
priori ceci ne correspond pas à des adresses réelles en mémoire
virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000 (exemple
pris pour la pile (stack) du processus), ce qui est bien au délà du giga
dont je dispose sur ma machine. (1 giga c'est de l'ordre de 0x30000000 il
me semble). Donc à quoi celà correspond ?
Ben... à des adresses en mémoire _virtuelle_. Chaque
processus a son propre espace d'adressage qui n'a aucun
(mais alors aucun) rapport avec l'adressage physique de
l'ordinateur.
Si tu regarde plus en détail, tu verras que _tous_ les
processus utilisent plus ou moins les même adresses, car ils
marchent tous de la même façon. Donc, chaque
processus a son code en 0x08048000, ses variables ensuite,
et ainsi de suite, et la magie de la vm de Linux replace ça
quelque part dans l'ordinateur (peut-être en RAM, peut-être
sur disque dans le swap), et le processus n'a même pas de
moyen de savoir où se trouvent physiquement ses données.Deuxième question : comment peut connaitre l'espace
d'adressage réel d'un processus (pour la pile par exemple)???
C'est définit au moment du link dans ld. En adresses
virtuelle, ça par de 0xc0000000 et ça va en descendant, en
général suffisament loin (à vue de nez, environ 7Mo sur mon
système, ça peut peut-être se régler, mais je ne pense pas
que qui que ce soit en ai déjà eu besoin :-)C'est assez important pour moi, donc si vous avez une semblant d'idée
n'hésitez pas. Merci ;)
J'ai une question en retour: pourquoi est-ce important? A
priori, ça ne devrait intéresser que ceux qui bidouillent le
compilateur, ou la partie vm du noyau.
Y.
Le Sat, 12 Nov 2005 01:40:15 +0100, Yves Rutschle a écrit :
> On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
>> Que représente le premier champ en début de ligne dans le fichier
maps?
>>
>> Dans le man il est écrit que c'est "l'espace d'adressage du
processus". A
>> priori ceci ne correspond pas à des adresses réelles en mémoire
>> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000
(exemple
>> pris pour la pile (stack) du processus), ce qui est bien au délà d u
giga
>> dont je dispose sur ma machine. (1 giga c'est de l'ordre de
0x30000000 il
>> me semble). Donc à quoi celà correspond ?
>
> Ben... à des adresses en mémoire _virtuelle_. Chaque
> processus a son propre espace d'adressage qui n'a aucun
> (mais alors aucun) rapport avec l'adressage physique de
> l'ordinateur.
>
> Si tu regarde plus en détail, tu verras que _tous_ les
> processus utilisent plus ou moins les même adresses, car ils
> marchent tous de la même façon. Donc, chaque
> processus a son code en 0x08048000, ses variables ensuite,
> et ainsi de suite, et la magie de la vm de Linux replace ça
> quelque part dans l'ordinateur (peut-être en RAM, peut-être
> sur disque dans le swap), et le processus n'a même pas de
> moyen de savoir où se trouvent physiquement ses données.
>
>> Deuxième question : comment peut connaitre l'espace
>> d'adressage réel d'un processus (pour la pile par exemple)???
>
> C'est définit au moment du link dans ld. En adresses
> virtuelle, ça par de 0xc0000000 et ça va en descendant, en
> général suffisament loin (à vue de nez, environ 7Mo sur mon
> système, ça peut peut-être se régler, mais je ne pense pas
> que qui que ce soit en ai déjà eu besoin :-)
>
>> C'est assez important pour moi, donc si vous avez une semblant
d'idée
>> n'hésitez pas. Merci ;)
>
> J'ai une question en retour: pourquoi est-ce important? A
> priori, ça ne devrait intéresser que ceux qui bidouillent le
> compilateur, ou la partie vm du noyau.
>
> Y.
Merci beaucoup à vous 2 pour ces réponses.
Ma deuxième question à mal été comprise, je crois :
En fait j'aimerai savoir, pour un processus donné, l'adresse réelle e n
mémoire (ram + swap confondue) des données. Cela me permettrait d'y
acceder au moyen de /dev/mem avec l'offset correspondant.
La mémoire virtuelle telle que vous la définissez ne m'interresse pas ,
ce que je veux c'est la véritable adresse en mémoire pour y acceder
via
/dev/mem. Je dis que c'est important pour moi car je suis en train de
coder un programme qui me permet de faire des recherches en mémoire,
et
des modifs, et j'aimerai pouvoir spécifier le processus dont on veut
modifier les données.
Merci pour vos (éventuelles) futures réponses.
--
Clément Plantier
Le Sat, 12 Nov 2005 01:40:15 +0100, Yves Rutschle a écrit :
> On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
>> Que représente le premier champ en début de ligne dans le fichier
maps?
>>
>> Dans le man il est écrit que c'est "l'espace d'adressage du
processus". A
>> priori ceci ne correspond pas à des adresses réelles en mémoire
>> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000
(exemple
>> pris pour la pile (stack) du processus), ce qui est bien au délà d u
giga
>> dont je dispose sur ma machine. (1 giga c'est de l'ordre de
0x30000000 il
>> me semble). Donc à quoi celà correspond ?
>
> Ben... à des adresses en mémoire _virtuelle_. Chaque
> processus a son propre espace d'adressage qui n'a aucun
> (mais alors aucun) rapport avec l'adressage physique de
> l'ordinateur.
>
> Si tu regarde plus en détail, tu verras que _tous_ les
> processus utilisent plus ou moins les même adresses, car ils
> marchent tous de la même façon. Donc, chaque
> processus a son code en 0x08048000, ses variables ensuite,
> et ainsi de suite, et la magie de la vm de Linux replace ça
> quelque part dans l'ordinateur (peut-être en RAM, peut-être
> sur disque dans le swap), et le processus n'a même pas de
> moyen de savoir où se trouvent physiquement ses données.
>
>> Deuxième question : comment peut connaitre l'espace
>> d'adressage réel d'un processus (pour la pile par exemple)???
>
> C'est définit au moment du link dans ld. En adresses
> virtuelle, ça par de 0xc0000000 et ça va en descendant, en
> général suffisament loin (à vue de nez, environ 7Mo sur mon
> système, ça peut peut-être se régler, mais je ne pense pas
> que qui que ce soit en ai déjà eu besoin :-)
>
>> C'est assez important pour moi, donc si vous avez une semblant
d'idée
>> n'hésitez pas. Merci ;)
>
> J'ai une question en retour: pourquoi est-ce important? A
> priori, ça ne devrait intéresser que ceux qui bidouillent le
> compilateur, ou la partie vm du noyau.
>
> Y.
Merci beaucoup à vous 2 pour ces réponses.
Ma deuxième question à mal été comprise, je crois :
En fait j'aimerai savoir, pour un processus donné, l'adresse réelle e n
mémoire (ram + swap confondue) des données. Cela me permettrait d'y
acceder au moyen de /dev/mem avec l'offset correspondant.
La mémoire virtuelle telle que vous la définissez ne m'interresse pas ,
ce que je veux c'est la véritable adresse en mémoire pour y acceder
via
/dev/mem. Je dis que c'est important pour moi car je suis en train de
coder un programme qui me permet de faire des recherches en mémoire,
et
des modifs, et j'aimerai pouvoir spécifier le processus dont on veut
modifier les données.
Merci pour vos (éventuelles) futures réponses.
--
Clément Plantier
Le Sat, 12 Nov 2005 01:40:15 +0100, Yves Rutschle a écrit :
> On Sat, Nov 12, 2005 at 12:25:59AM +0100, Clément Plantier wrote:
>> Que représente le premier champ en début de ligne dans le fichier
maps?
>>
>> Dans le man il est écrit que c'est "l'espace d'adressage du
processus". A
>> priori ceci ne correspond pas à des adresses réelles en mémoire
>> virtuelle : on peut voir des valeurs allant jusqu'à 0xbfb19000
(exemple
>> pris pour la pile (stack) du processus), ce qui est bien au délà d u
giga
>> dont je dispose sur ma machine. (1 giga c'est de l'ordre de
0x30000000 il
>> me semble). Donc à quoi celà correspond ?
>
> Ben... à des adresses en mémoire _virtuelle_. Chaque
> processus a son propre espace d'adressage qui n'a aucun
> (mais alors aucun) rapport avec l'adressage physique de
> l'ordinateur.
>
> Si tu regarde plus en détail, tu verras que _tous_ les
> processus utilisent plus ou moins les même adresses, car ils
> marchent tous de la même façon. Donc, chaque
> processus a son code en 0x08048000, ses variables ensuite,
> et ainsi de suite, et la magie de la vm de Linux replace ça
> quelque part dans l'ordinateur (peut-être en RAM, peut-être
> sur disque dans le swap), et le processus n'a même pas de
> moyen de savoir où se trouvent physiquement ses données.
>
>> Deuxième question : comment peut connaitre l'espace
>> d'adressage réel d'un processus (pour la pile par exemple)???
>
> C'est définit au moment du link dans ld. En adresses
> virtuelle, ça par de 0xc0000000 et ça va en descendant, en
> général suffisament loin (à vue de nez, environ 7Mo sur mon
> système, ça peut peut-être se régler, mais je ne pense pas
> que qui que ce soit en ai déjà eu besoin :-)
>
>> C'est assez important pour moi, donc si vous avez une semblant
d'idée
>> n'hésitez pas. Merci ;)
>
> J'ai une question en retour: pourquoi est-ce important? A
> priori, ça ne devrait intéresser que ceux qui bidouillent le
> compilateur, ou la partie vm du noyau.
>
> Y.
Merci beaucoup à vous 2 pour ces réponses.
Ma deuxième question à mal été comprise, je crois :
En fait j'aimerai savoir, pour un processus donné, l'adresse réelle e n
mémoire (ram + swap confondue) des données. Cela me permettrait d'y
acceder au moyen de /dev/mem avec l'offset correspondant.
La mémoire virtuelle telle que vous la définissez ne m'interresse pas ,
ce que je veux c'est la véritable adresse en mémoire pour y acceder
via
/dev/mem. Je dis que c'est important pour moi car je suis en train de
coder un programme qui me permet de faire des recherches en mémoire,
et
des modifs, et j'aimerai pouvoir spécifier le processus dont on veut
modifier les données.
Merci pour vos (éventuelles) futures réponses.
--
Clément Plantier
>Ma deuxième question à mal été comprise, je crois : En
>fait j'aimerai savoir, pour un processus donné, l'adresse
>réelle en mémoire (ram + swap confondue) des données.
>Cela me permettrait d'y acceder au moyen de /dev/mem avec
>l'offset correspondant. La mémoire virtuelle telle que
>vous la définissez ne m'interresse pas, ce que je veux
>c'est la véritable adresse en mémoire pour y acceder via
>/dev/mem.
>Je dis que c'est important pour moi car je suis en train
>de coder un programme qui me permet de faire des
>recherches en mémoire, et des modifs, et j'aimerai
>pouvoir spécifier le processus dont on veut modifier les
>données.
Ça, je ne sais aps si on peut l'obtenir facilement.
>Ma deuxième question à mal été comprise, je crois : En
>fait j'aimerai savoir, pour un processus donné, l'adresse
>réelle en mémoire (ram + swap confondue) des données.
>Cela me permettrait d'y acceder au moyen de /dev/mem avec
>l'offset correspondant. La mémoire virtuelle telle que
>vous la définissez ne m'interresse pas, ce que je veux
>c'est la véritable adresse en mémoire pour y acceder via
>/dev/mem.
>Je dis que c'est important pour moi car je suis en train
>de coder un programme qui me permet de faire des
>recherches en mémoire, et des modifs, et j'aimerai
>pouvoir spécifier le processus dont on veut modifier les
>données.
Ça, je ne sais aps si on peut l'obtenir facilement.
>Ma deuxième question à mal été comprise, je crois : En
>fait j'aimerai savoir, pour un processus donné, l'adresse
>réelle en mémoire (ram + swap confondue) des données.
>Cela me permettrait d'y acceder au moyen de /dev/mem avec
>l'offset correspondant. La mémoire virtuelle telle que
>vous la définissez ne m'interresse pas, ce que je veux
>c'est la véritable adresse en mémoire pour y acceder via
>/dev/mem.
>Je dis que c'est important pour moi car je suis en train
>de coder un programme qui me permet de faire des
>recherches en mémoire, et des modifs, et j'aimerai
>pouvoir spécifier le processus dont on veut modifier les
>données.
Ça, je ne sais aps si on peut l'obtenir facilement.
Pareil. À mon avis, tu pars sur la mauvaise piste. Je te
conseillerais de regarder comment les debuggeurs marchent:
gdb sait regarder la mémoire d'un autre processus, et ce
sans se soucier d'où elle est physiquement.
Y.
Pareil. À mon avis, tu pars sur la mauvaise piste. Je te
conseillerais de regarder comment les debuggeurs marchent:
gdb sait regarder la mémoire d'un autre processus, et ce
sans se soucier d'où elle est physiquement.
Y.
Pareil. À mon avis, tu pars sur la mauvaise piste. Je te
conseillerais de regarder comment les debuggeurs marchent:
gdb sait regarder la mémoire d'un autre processus, et ce
sans se soucier d'où elle est physiquement.
Y.
Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
On Sun, Nov 13, 2005 at 01:29:18PM +0100, Clément Plantier wrote:Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
Non, gdb peut aussi s'attacher à un PID qui tourne déjà.
C'est exactement ce que tu veux faire. (En fait, tu pourrais
simplement développer autour de gdb par sa ligne de
commande: lancer gdb, récupérer les infos qu'il indique sur
la pile, le tas, etc. Ça a l'avantage d'être portable,
contrairement à la bidouille dans /proc qui peut ne pas
marcher d'une version de Linux à une autre).
Y.
On Sun, Nov 13, 2005 at 01:29:18PM +0100, Clément Plantier wrote:
Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
Non, gdb peut aussi s'attacher à un PID qui tourne déjà.
C'est exactement ce que tu veux faire. (En fait, tu pourrais
simplement développer autour de gdb par sa ligne de
commande: lancer gdb, récupérer les infos qu'il indique sur
la pile, le tas, etc. Ça a l'avantage d'être portable,
contrairement à la bidouille dans /proc qui peut ne pas
marcher d'une version de Linux à une autre).
Y.
On Sun, Nov 13, 2005 at 01:29:18PM +0100, Clément Plantier wrote:Le Sun, 13 Nov 2005 12:50:16 +0100, Yves Rutschle a écrit :
Le problème c'est que gdb lance lui même un processus fils a debugger,
et donc je pense que c'est plus simple pour lui d'acceder aux données de
ce processus qu'il a créé...
Non, gdb peut aussi s'attacher à un PID qui tourne déjà.
C'est exactement ce que tu veux faire. (En fait, tu pourrais
simplement développer autour de gdb par sa ligne de
commande: lancer gdb, récupérer les infos qu'il indique sur
la pile, le tas, etc. Ça a l'avantage d'être portable,
contrairement à la bidouille dans /proc qui peut ne pas
marcher d'une version de Linux à une autre).
Y.
