Tiens au fait toi qui parle volontiers "d'engueulo, de franche
camaraderie, de docte". Que dirais tu toi même de ta propre
intervention là ? LOL
Faites ce que je dis mais ne faites pas ce que je fais, le principe
d'Arnold ?
Tiens au fait toi qui parle volontiers "d'engueulo, de franche
camaraderie, de docte". Que dirais tu toi même de ta propre
intervention là ? LOL
Faites ce que je dis mais ne faites pas ce que je fais, le principe
d'Arnold ?
Tiens au fait toi qui parle volontiers "d'engueulo, de franche
camaraderie, de docte". Que dirais tu toi même de ta propre
intervention là ? LOL
Faites ce que je dis mais ne faites pas ce que je fais, le principe
d'Arnold ?
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça
non ?
Alors, je compile cette fonction, et je le lie dans une DLL.
Je charge la DLL dans deux processus différents, dont les
données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll
autour de ta fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le
fichier PE y trouve une section "données" contenant au moins
ta variable static et que lors du chargement il crée une zone
en mémoire (une par process si plusieurs utilisent la dll)
contenant cette variable.
Je dis je suppose parce que pour être certain à 100% il
faudrait examiner le fichier binaire PE, mais je ne pense pas
me tromper toutefois. Quand l'appli va lire la valeur elle le
fait avec un pointeur qui vaut 10017198h dans l'exemple. Mais
cette adresse est toute virtuelle.
Quand elle est lue le système fait ce qu'il faut pour que la
variable appartenant au process soit lue effectivement en
mémoire physique. Et chaque process à sa propre copie de la
variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise tant. On
dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça
non ?
Alors, je compile cette fonction, et je le lie dans une DLL.
Je charge la DLL dans deux processus différents, dont les
données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll
autour de ta fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le
fichier PE y trouve une section "données" contenant au moins
ta variable static et que lors du chargement il crée une zone
en mémoire (une par process si plusieurs utilisent la dll)
contenant cette variable.
Je dis je suppose parce que pour être certain à 100% il
faudrait examiner le fichier binaire PE, mais je ne pense pas
me tromper toutefois. Quand l'appli va lire la valeur elle le
fait avec un pointeur qui vaut 10017198h dans l'exemple. Mais
cette adresse est toute virtuelle.
Quand elle est lue le système fait ce qu'il faut pour que la
variable appartenant au process soit lue effectivement en
mémoire physique. Et chaque process à sa propre copie de la
variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise tant. On
dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Hum, l'adressage par rapport à DS c'est du temps du 16 bits ça
non ?
Alors, je compile cette fonction, et je le lie dans une DLL.
Je charge la DLL dans deux processus différents, dont les
données, etc., se trouvent à des adresses différentes.
Comment fait Windows pour que ce bout de code fonctionne ?
Poussés par la curiosité et ton insistance, j'ai fait une dll
autour de ta fonction et désassemblé, ça donne:
__declspec( dllexport ) int ma_fonction()
{
10011300 push ebp
10011301 mov ebp,esp
10011303 sub esp,0C4h
10011309 push ebx
1001130A push esi
1001130B push edi
1001130C lea edi,[ebp-0C4h]
10011312 mov ecx,31h
10011317 mov eax,0CCCCCCCCh
1001131C rep stos dword ptr es:[edi]
static int i = 0 ;
return i ++ ;
1001131E mov eax,dword ptr [i (10017168h)]
10011323 mov dword ptr [ebp-0C4h],eax
10011329 mov ecx,dword ptr [i (10017168h)]
1001132F add ecx,1
10011332 mov dword ptr [i (10017168h)],ecx
10011338 mov eax,dword ptr [ebp-0C4h]
}
1001133E pop edi
1001133F pop esi
10011340 pop ebx
10011341 mov esp,ebp
10011343 pop ebp
10011344 ret
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Et je suppose qu'au démarrage de l'appli le système qui lit le
fichier PE y trouve une section "données" contenant au moins
ta variable static et que lors du chargement il crée une zone
en mémoire (une par process si plusieurs utilisent la dll)
contenant cette variable.
Je dis je suppose parce que pour être certain à 100% il
faudrait examiner le fichier binaire PE, mais je ne pense pas
me tromper toutefois. Quand l'appli va lire la valeur elle le
fait avec un pointeur qui vaut 10017198h dans l'exemple. Mais
cette adresse est toute virtuelle.
Quand elle est lue le système fait ce qu'il faut pour que la
variable appartenant au process soit lue effectivement en
mémoire physique. Et chaque process à sa propre copie de la
variable static i bien entendu.
En fait je ne comprends pas bien ce qui te défrise tant. On
dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
Commence par lire les archives de ce NG avant de me chercher.
Commence par lire les archives de ce NG avant de me chercher.
Commence par lire les archives de ce NG avant de me chercher.
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'ai modifié la fonction pour renvoyer l'adresse de i, que
j'affiche. Parfois, c'est 0x00231000, parfois 0x100217C0. Jamais
dans les 2Go supérieur, mais même pas toujours à la même
adresse, dans deux processus qui tournent au même temps.
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'ai modifié la fonction pour renvoyer l'adresse de i, que
j'affiche. Parfois, c'est 0x00231000, parfois 0x100217C0. Jamais
dans les 2Go supérieur, mais même pas toujours à la même
adresse, dans deux processus qui tournent au même temps.
Il me semble qu'il est clair que ta variable static est dans
la zone des 2 go supérieure.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'ai modifié la fonction pour renvoyer l'adresse de i, que
j'affiche. Parfois, c'est 0x00231000, parfois 0x100217C0. Jamais
dans les 2Go supérieur, mais même pas toujours à la même
adresse, dans deux processus qui tournent au même temps.
"kanze" wrote in message
news:
Vincent Burel wrote:"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS,
en tout cas).
ben les différentes hinstance de la DLL travaille avec les
mêmes adresses 32 bit (logiques), mais chaque appli à ses 6
segments sauvé dans sont swith context, et chaque segements
décrivent des zones différentes...
Après, vous etes sur que le compilo est capable d'user
d'adresse vraiment constante ?
genre un nombre codé en dur dans le code ASM ? ca me parait
bizarre !
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui
ne le connais pas.
ha oui c'est vrai que tout le monde connais ca sur le bout des
doigt !
d'ailleurs ce thread en ai la preuve :-)
Et je constate également qu'à l'intérieur d'un processus, on
ne touche normalement pas à DS -- si la fonction renvoie
l'adresse, par exemple, il
renvoie bien l'offset, sans renseigner sur le segment
une appli user, ne gère par d'adresse seg:offset, il n'utilise
que l'offset.
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
pourquoi ? justement le mappage permet ca !
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157979572.331719.273090@e3g2000cwe.googlegroups.com...
Vincent Burel wrote:
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157956613.844273.280450@d34g2000cwd.googlegroups.com...
Vincent Burel wrote:
"James Kanze" <kanze.james@neuf.fr> wrote in message
news:1157885071.765095.141990@m79g2000cwm.googlegroups.com...
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS,
en tout cas).
ben les différentes hinstance de la DLL travaille avec les
mêmes adresses 32 bit (logiques), mais chaque appli à ses 6
segments sauvé dans sont swith context, et chaque segements
décrivent des zones différentes...
Après, vous etes sur que le compilo est capable d'user
d'adresse vraiment constante ?
genre un nombre codé en dur dans le code ASM ? ca me parait
bizarre !
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui
ne le connais pas.
ha oui c'est vrai que tout le monde connais ca sur le bout des
doigt !
d'ailleurs ce thread en ai la preuve :-)
Et je constate également qu'à l'intérieur d'un processus, on
ne touche normalement pas à DS -- si la fonction renvoie
l'adresse, par exemple, il
renvoie bien l'offset, sans renseigner sur le segment
une appli user, ne gère par d'adresse seg:offset, il n'utilise
que l'offset.
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
pourquoi ? justement le mappage permet ca !
"kanze" wrote in message
news:
Vincent Burel wrote:"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
ben c'est à dire que chaque "task" s'exécute dans un
environnement mémoire propre, et en fonction d'une table de
mappage mem-phy <-> mem logique spécique. Quand le programme
fait appel à une adresse 32 bit, c'est toujours dans un
contexte mémoire donné...
Certes, mais qu'est-ce que ça change ? Je parle bien ici de
l'adresse dans l'espace d'adressage d'un processus. Le
compilateur génère une adresse constante (par rapport à DS,
en tout cas).
ben les différentes hinstance de la DLL travaille avec les
mêmes adresses 32 bit (logiques), mais chaque appli à ses 6
segments sauvé dans sont swith context, et chaque segements
décrivent des zones différentes...
Après, vous etes sur que le compilo est capable d'user
d'adresse vraiment constante ?
genre un nombre codé en dur dans le code ASM ? ca me parait
bizarre !
Tout ça c'est bien beau, même si j'imagine mal quelqu'un qui
ne le connais pas.
ha oui c'est vrai que tout le monde connais ca sur le bout des
doigt !
d'ailleurs ce thread en ai la preuve :-)
Et je constate également qu'à l'intérieur d'un processus, on
ne touche normalement pas à DS -- si la fonction renvoie
l'adresse, par exemple, il
renvoie bien l'offset, sans renseigner sur le segment
une appli user, ne gère par d'adresse seg:offset, il n'utilise
que l'offset.
Seulement, c'est impossible que l'adresse logique soit
la même dans tous les processus.
pourquoi ? justement le mappage permet ca !
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
"kanze" wrote in message
news:
Vincent Burel wrote:"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
Si l'éditeur de liens a l'information des besoins de tous les
processus, il se peut qu'il trouve une solution, mais ce n'est
pas sûr. Mais de toute façon, il ne l'est pas. Si l'éditeur de
liens (ou le système) met la variable à l'adresse 0x1000CCA0,
par exemple, comment s'en sort-il quand le prochain processus
veut charger la DLL, et qu'il a déjà quelque chose à cette
adresse ? (On parle ici bien des adresses logiques à
l'interieur du processus. Et que de ces adresses.)
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157979572.331719.273090@e3g2000cwe.googlegroups.com...
Vincent Burel wrote:
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157956613.844273.280450@d34g2000cwd.googlegroups.com...
Vincent Burel wrote:
"James Kanze" <kanze.james@neuf.fr> wrote in message
news:1157885071.765095.141990@m79g2000cwm.googlegroups.com...
Alain Gaillard wrote:
Si l'éditeur de liens a l'information des besoins de tous les
processus, il se peut qu'il trouve une solution, mais ce n'est
pas sûr. Mais de toute façon, il ne l'est pas. Si l'éditeur de
liens (ou le système) met la variable à l'adresse 0x1000CCA0,
par exemple, comment s'en sort-il quand le prochain processus
veut charger la DLL, et qu'il a déjà quelque chose à cette
adresse ? (On parle ici bien des adresses logiques à
l'interieur du processus. Et que de ces adresses.)
"kanze" wrote in message
news:
Vincent Burel wrote:"kanze" wrote in message
news:
Vincent Burel wrote:"James Kanze" wrote in message
news:
Alain Gaillard wrote:
Si l'éditeur de liens a l'information des besoins de tous les
processus, il se peut qu'il trouve une solution, mais ce n'est
pas sûr. Mais de toute façon, il ne l'est pas. Si l'éditeur de
liens (ou le système) met la variable à l'adresse 0x1000CCA0,
par exemple, comment s'en sort-il quand le prochain processus
veut charger la DLL, et qu'il a déjà quelque chose à cette
adresse ? (On parle ici bien des adresses logiques à
l'interieur du processus. Et que de ces adresses.)
Je préviens (surtout qu'il y a un crosspost où peu de gens
doivent me connaîre) que je ne connais rien à Windows.
Alain Gaillard writes:g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Je suppose qu'il s'agit de -fpic et pas -fpei.
En fait je ne comprends pas bien ce qui te défrise
tant.
Je crains que tu ne comprennes pas la question.
Cela fait longtemps que j'ai fait de l'assembleur avec la
syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu: donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs. Il faut donc que i ait
la même adresse dans tous les process si le code est
réellement partagé. Comment Windows fait pour s'assurer que
toutes les DLL sont bien mappées pour où elles ont été
compilées?
Soit le code n'est pas partagé et Windows fait de la
relocation au chargment (ce que fait Solaris quand un .so
n'est pas compilé en PIC -- on pourrait faire de la relocation
"intelligente" et essayer de charger la lib généralement au
même endroit, je doute que ce soit fait sous Solaris car le
chargeur est un exécutable sans droits supplémentaires et donc
sans influence sur les autres processus), soit il s'arrange
pour que 10017168h désigne des adresses différentes suivant
les endroits où il est appelé, et la seule façon que je vois,
c'est de modifier la base indiquée pas DS.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
Les segments sont toujours sur un x86 (enfin, plus en mode 64
bits si j'ai bien suivi), simplement on ne les utilise pas
beaucoup dans les OS répandus. Mais il y a des utilisations,
par exemple je crois savoir que Windows les utilise aussi pour
"pointer" vers les variables locales à des threads et les
utiliser pour les DLL, ça ne me semble pas stupide étant donné
que les x86 sont quand même mal foutus quand on veut écrire du
code PIC.
Je préviens (surtout qu'il y a un crosspost où peu de gens
doivent me connaîre) que je ne connais rien à Windows.
Alain Gaillard <alain_gaillard28@hotmail.fr> writes:
g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Je suppose qu'il s'agit de -fpic et pas -fpei.
En fait je ne comprends pas bien ce qui te défrise
tant.
Je crains que tu ne comprennes pas la question.
Cela fait longtemps que j'ai fait de l'assembleur avec la
syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu: donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs. Il faut donc que i ait
la même adresse dans tous les process si le code est
réellement partagé. Comment Windows fait pour s'assurer que
toutes les DLL sont bien mappées pour où elles ont été
compilées?
Soit le code n'est pas partagé et Windows fait de la
relocation au chargment (ce que fait Solaris quand un .so
n'est pas compilé en PIC -- on pourrait faire de la relocation
"intelligente" et essayer de charger la lib généralement au
même endroit, je doute que ce soit fait sous Solaris car le
chargeur est un exécutable sans droits supplémentaires et donc
sans influence sur les autres processus), soit il s'arrange
pour que 10017168h désigne des adresses différentes suivant
les endroits où il est appelé, et la seule façon que je vois,
c'est de modifier la base indiquée pas DS.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
Les segments sont toujours sur un x86 (enfin, plus en mode 64
bits si j'ai bien suivi), simplement on ne les utilise pas
beaucoup dans les OS répandus. Mais il y a des utilisations,
par exemple je crois savoir que Windows les utilise aussi pour
"pointer" vers les variables locales à des threads et les
utiliser pour les DLL, ça ne me semble pas stupide étant donné
que les x86 sont quand même mal foutus quand on veut écrire du
code PIC.
Je préviens (surtout qu'il y a un crosspost où peu de gens
doivent me connaîre) que je ne connais rien à Windows.
Alain Gaillard writes:g++ -fpei sous Linux, par exemple). Cet offset, c'est par
rapport à DS.
Je suppose qu'il s'agit de -fpic et pas -fpei.
En fait je ne comprends pas bien ce qui te défrise
tant.
Je crains que tu ne comprennes pas la question.
Cela fait longtemps que j'ai fait de l'assembleur avec la
syntaxe MS -- mais il me semble que
mov eax,dword ptr [i (10017168h)]
c'est de l'adressage absolu: donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs. Il faut donc que i ait
la même adresse dans tous les process si le code est
réellement partagé. Comment Windows fait pour s'assurer que
toutes les DLL sont bien mappées pour où elles ont été
compilées?
Soit le code n'est pas partagé et Windows fait de la
relocation au chargment (ce que fait Solaris quand un .so
n'est pas compilé en PIC -- on pourrait faire de la relocation
"intelligente" et essayer de charger la lib généralement au
même endroit, je doute que ce soit fait sous Solaris car le
chargeur est un exécutable sans droits supplémentaires et donc
sans influence sur les autres processus), soit il s'arrange
pour que 10017168h désigne des adresses différentes suivant
les endroits où il est appelé, et la seule façon que je vois,
c'est de modifier la base indiquée pas DS.
On dirait que tu raisonnes comme si l'adressage était à
l'ancienne en 16 bits (registre DS...) à moins que je ne
comprenne pas ta question.
Les segments sont toujours sur un x86 (enfin, plus en mode 64
bits si j'ai bien suivi), simplement on ne les utilise pas
beaucoup dans les OS répandus. Mais il y a des utilisations,
par exemple je crois savoir que Windows les utilise aussi pour
"pointer" vers les variables locales à des threads et les
utiliser pour les DLL, ça ne me semble pas stupide étant donné
que les x86 sont quand même mal foutus quand on veut écrire du
code PIC.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse physique à
laquelle elle correspond devrait elle être la me^me pour chaque proc.
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors ce sera
la même adresse physique et alors le code est partagé. Si l'adresse
pointe sur des données, alors l'adresse physique correspondante est
différente pour chaque processus qui a sa copie en mémoire physique des
données.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.
J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse physique à
laquelle elle correspond devrait elle être la me^me pour chaque proc.
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors ce sera
la même adresse physique et alors le code est partagé. Si l'adresse
pointe sur des données, alors l'adresse physique correspondante est
différente pour chaque processus qui a sa copie en mémoire physique des
données.
Tu crois ? Si l'adresse, c'est bien 0x10017168, elle n'est pas
dans les 2Go supérieur, mais dans le deuxième banc de 1Go, entre
1Go et 2Go.
Heu.. hem je me suis trompé d'un zéro.J'avoue que j'ai assez de mal à l'expliquer clairement. Le
problème, si tu veux, c'est ce qui se passe si je démarre
processus A, qui utilise cette DLL, et qu'on mappe bien la
variable à l'adresse 0x100217C0. Qu'est-ce qui se passe ensuite
si un processus B démande la même DLL, et qu'il a déjà quelque
chose mappée à cette adresse (toujours, dans son espace
d'adressage logique à lui).
Ce 0x100217C0 étant une adresse virtuelle, pourquoi l'adresse physique à
laquelle elle correspond devrait elle être la me^me pour chaque proc.
Elle peut l'être ou pas. Si l'adresse pointe sur du code alors ce sera
la même adresse physique et alors le code est partagé. Si l'adresse
pointe sur des données, alors l'adresse physique correspondante est
différente pour chaque processus qui a sa copie en mémoire physique des
données.
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux
process utilisant la meme DLL, je ne
suis pas certain que cette DLL ne soit pas physiquement chargé 2 fois..."
:-)
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux
process utilisant la meme DLL, je ne
suis pas certain que cette DLL ne soit pas physiquement chargé 2 fois..."
:-)
Vous allez voir qu'on va revenir à ma réflexion de départ : "Pour deux
process utilisant la meme DLL, je ne
suis pas certain que cette DLL ne soit pas physiquement chargé 2 fois..."
:-)
