Discussion :

[LEK]

Bonjour,
en lisant les cours de C/C++ sur le site j'ai cru comprendre que lorsqu'une variable était déclarée et affectée, lors de l'exécution du programme l'os réservait une adresse mémoire particulière à cette variable pour y stocker son contenu... Enfin c'est ce que je croyais : qu'on ne pouvait pas savoir à l'avance où en mémoire serait stocké telle ou telle variable..
Mais je viens de lire un article sur une développement VC++ qui indique comment lire un processus en mémoire ( : avec la fonction ReadProcessMemory) => l'exemple montre comment déterminer la valeur de certaine variable en lisant directement à une certaine adresse, donc cela revienbdrait à dire que les adresses mémoires où sont stocker les valeurs de variables sont déterminées à la compilation et non à l'exécution, non ?
Je ne sais pas si j'ai loupé quelquechose mais les cours en ligne ne précisent pas ce point où alors je ne comprend pas comment cela fonctionne...
Car si les adresses mémoires sont définies par le compilateur alors deux programmes différents pourraient potentiellement vouloir écrire une valeur à la même adresse mémoire ?
En tous cas merci pour vos éclaircissements,
Lek.

[koala01]

Salut,

C'est en fait plus compliqué que cela...

Pour essayer de te faire comprendre, je vais faire "au plus simple", ce qui signifie, fatalement, que ce ne sera pas tout à fait juste

Lorsque tu compile un programme, il fait une certaine taille (que tu peux, par exemple, voir dans ton explorateur de fichiers), et il est "simplement" écrit sur le disque dur.

Lorsque tu décide d'exécuter ce programme, il va être chargé en mémoire, afin de pouvoir être utilisé.

On peu donc estimer que, si un programme a une taille T et que la première adresse mémoire qu'il utilise lorsqu'il est chargé en mémoire est M, qu'il va utiliser toutes les adresse mémoire comprises entre M et M+T

Seulement, tu comprendra qu'il est largement préférable de faire en sorte que les adresses mémoires situées entre M et M+T ne soient pas utilisées par d'autres programmes...

C'est là qu'intervient le système d'exploitation en gardant une trace de tous les "blocs mémoires" (pour faire simple, disons qu'un bloc représente une série d'adresses contigues) disponibles, et de leur taille.

Lorsque tu lances ton programme, le système d'exploitation va donc chercher un endroit parmi les blocs mémoire disponibles qui soit au minimum suffisemment grand pour... permettre de charger le programme en mémoire, et, au besoin "faire un peu le ménage" (par exemple, en plaçant certaines informations dont il estime ne pas avoir un besoin immédiat dans le "swap" (la mémoire virtuelle) ).

Pour les variables créées statiquement (par opposition aux variables pour lesquelles on recours à l'allocation dynamique de la mémoire), elles ont une taille bien définies qui intervient, bon an mal an, dans la taille générale du programme.

Leur adresse "relative" (par rapport à l'adresse à laquelle se trouve le début du programme) est connue, mais, comme l'adresse à laquelle se trouve le début du programme sera déterminée par le système d'exploitation, leur adresse "absolue" (qui est celle qui nous intéresse réellement) sera différente à chaque exécution du programme (ou en tout cas, susceptible de l'être)

En ce qui concerne les variables créées dynamiquement (en ayant recours à l'allocation dynamique de la mémoire), nous savons, par l'intermédiaire de l'opérateur sizeof, quel espace mémoire est nécessaire pour représenter un exemplaire, mais nous ne savons pas combien d'exemplaires il faut prévoir, car cela dépend des circonstances.

malloc va donc s'adresser "directement" au système d'exploitation pour lui demander de nous trouver un espace mémoire suffisant pour... y loger le nombre d'exemplaire du type souhaité.

Le système d'exploitation agira alors de manière fort similaire à ce qu'il fait lors du chargement du programme: il cherchera, parmi les différents blocs mémoire qui sont disponibles, celui qui fournira suffisamment d'espace pour y loger les données.

Inversement, free va signaler au système d'exploitation que l'espace mémoire que l'on a demandé avec malloc est à nouveau disponible, éventuellement pour une autre application.

Enfin, en ce qui concerne les fonctions ReadProcessMemory et associées, ce sont, pour faire simple, des fonctions qui permettent de... dialoguer avec le système d'exploitation, au même titre que malloc ou que free.

Car, s'il y a une "chose" qui sait (normalement) en permanence où sont chargées les différentes application qui s'exécutent sur un ordinateur, c'est... le système d'exploitation...

On *peut* donc lui demander "n'importe quand" l'adresse à laquelle se trouve le début de telle ou telle application, et l'utiliser "à sa guise" (ou peu s'en faut).

Il faut cependant savoir que ReadProcessMemory est une fonction typique de windows, et que, bien qu'il existe surement un mécanisme similaire sous linux, le nom ainsi, peut-être, que l'ordre ou le nombre de paramètres à transmettre à cette instruction, est très vraisemblablement différent

[LEK]

super !
Merci Koala1,
pour cette explication, cela me semble beaucoup plus clair maintenant.
Saurais-tu où je pourrais lire des infos sur le sujet ? c'est purement pour la culture personnelle mais ça à l'air passionant : je me suis toujours demander comment le code compilé pouvait bien se stocker sur disque et ensuite être chargé pour s'exécuté en mémoire...
D'un autre côté existe-t-il des librairies multiplateforme pour réaliser ce genre de tâches (je parle d'ensapsulation de readmemoryaccess pour windows) ? J'imagine que c'est ce que dois utiliser un débugger multiplateforme...
En tous cas mille merci pour cette brillante et limpide explication.
Lek.

[koala01]

super !
Merci Koala1,
pour cette explication, cela me semble beaucoup plus clair maintenant.

Attention, elle a été simplifiée au maximum pour permettre la compréhension...

Je te rappelle que ce n'est donc, forcément, pas "tout à fait juste" (et peut être encore beaucoup plus faux que tu ne pourrais l'imaginer )

Saurais-tu où je pourrais lire des infos sur le sujet ? c'est purement pour la culture personnelle mais ça à l'air passionant : je me suis toujours demander comment le code compilé pouvait bien se stocker sur disque et ensuite être chargé pour s'exécuté en mémoire...

Houla...

On sort du domaine de la programmation, là, pour aborder celui du fonctionnement hardware...

Je n'ai pas de référence sous la main, mais, si j'étais toi, j'irais peut être faire un tour du côté de la section hardware du site ou des tutoriels expliquant le fonctionnement interne du matériel

D'un autre côté existe-t-il des librairies multiplateforme pour réaliser ce genre de tâches (je parle d'ensapsulation de readmemoryaccess pour windows) ? J'imagine que c'est ce que dois utiliser un débugger multiplateforme...

Cela se fait, le plus souvent, à coup de directives de compilation conditionnelles, sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#if defined(__WINDOWS__)
/* directive supplémentaires pour déterminer quel windows, voire, quel 
 *compilo et / ou le langage utilisé
 */
#else if defined (__LINUX__)
/* directive supplémentaires pour déterminer quel linux, voire, quel 
 *compilo et / ou le langage utilisé
 */
#endif

Je ne me suis jamais réellement intéressé au domaine de la programmation des débuggeurs, mais cela peut, effectivement, être ce qu'ils utilisent...

A moins qu'ils ne décident de créer un thread dans lequel ils invoquent l'application ... Va savoir

[LEK]

Bon quoiqu'il en soit je te remercie pour tes éclaircissements.
Je reviendrais mettre à jour ce post si j'en appends plus...
@+,
Lek.