Bonjour
j'utilise un board de developpement (snowball) embarquant un processeur ARM cortex A9 MPCore. tournant sous un linux avec un kernel 3.0.8+. J'utilise GDB et OPENOCD pour faire du debug.
Je cherche un moyen d'identifier les adresses mémoire d'un processus en mode user, et plus precisement les section text et la stack user.
j'ai d'abord regardé dans /proc/"PID"/maps et pour un processus user j'obtien ce qui suit:
Puis j'ai ecrit un script GDB qui parcours la liste des processus en commençant par init_task. Pour chaque processus j'extrai les valeurs start_code, end_code et start_stack, se trouvant dans la structure pointée par le champ mm de la structure task_struct du processus. Enfin j'extrai les diffèrentes regions mémoire se trouvant dans une liste pointée par mmap.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 # cat /proc/1124/maps 00008000-000d5000 r-xp 00000000 b3:02 181 /system/bin/lbsd 000d5000-000f8000 rw-p 000cd000 b3:02 181 /system/bin/lbsd 000f8000-0014a000 rw-p 00000000 00:00 0 [heap] 0014a000-0014c000 rw-p 00000000 00:00 0 [heap] . . . b0001000-b0009000 r-xp 00001000 b3:02 183 /system/bin/linker b0009000-b000a000 rw-p 00009000 b3:02 183 /system/bin/linker b000a000-b0015000 rw-p 00000000 00:00 0 bea00000-bea21000 rw-p 00000000 00:00 0 [stack] ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
Le script s'execute dans GDB installé sur une machine hote et reliée à la board en JTAG, OPENOCD gère la partie JTAG. Lors de l'execution le processeur et en mode debug et les deux coeur sont arrétés.
j'obtient les valeurs suivantes(pour le meme processus de la premiere méthode):
Le première chose que je ne comprend pas est la différence dans l'addresse de la stack entre les deux methodes:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47 taskaddr 0xdf29f140 Name: lbsd mm start text 8000 mm end text d4ba4 mm start stack bee63df0 ####MEMORY REGIONS##### vm_start 0x8000 vm_end 0xd5000 vm_flags 0x8001875 ----------------------- vm_start 0xd5000 vm_end 0xf8000 vm_flags 0x8101873 ----------------------- vm_start 0xf8000 vm_end 0x14a000 vm_flags 0x100073 ----------------------- vm_start 0x14a000 vm_end 0x14c000 vm_flags 0x100073 ----------------------- . . . ----------------------- vm_start 0xb0001000 vm_end 0xb0009000 vm_flags 0x8000875 ----------------------- vm_start 0xb0009000 vm_end 0xb000a000 vm_flags 0x8100873 ----------------------- vm_start 0xb000a000 vm_end 0xb0015000 vm_flags 0x100073 ----------------------- vm_start 0xbee42000 vm_end 0xbee64000 vm_flags 0x100173 ----------------------- vm_start 0xffff0000 vm_end 0xffff1000 vm_flags 0x40c0055 -----------------------
en lisant /proc/.../maps, la satck semble se trouver entre 0xbea00000 et 0xbea21000
dans le champ start_stack elle a 0xbee63df0
et dans mmap elle semble se trouver entre 0xbee42000 et 0xbee64000
La deuxième question concerne l'adresse de la section text du programme dans les deux methodes elle semble se trouver entre 0x8000 et 0xd5000, ce qui ne me semble pas etre une addresse valide, d'autant plus que d'autre processus ont leur section text au meme endroit.
Quelqu'un peut il m'expliquer comment fait le noyau pour retrouver les veritable addresses?
Merci
Partager