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:
Je reviens sur la question. Donc oui ici.donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs.
Mais non là.
Je pense que le mode d'adressage virtuel des Intel 32 bits
t'échappe
Voilà pourquoi une adresse virtuelle donnée va pointer
vers des adresses physiques différentes selon le
processus. Quand Windows charge un exe il construit cette
table (table qui n'est pas la table de saut en mémoire
haute dont j'ai parlé avant, ça tombe sous le sens), donc
à priori différentes pour chaque processus, même si elle
peuvent avoir des points communs, comme le code partagé
des dll.
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:
Je reviens sur la question. Donc oui ici.
donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs.
Mais non là.
Je pense que le mode d'adressage virtuel des Intel 32 bits
t'échappe
Voilà pourquoi une adresse virtuelle donnée va pointer
vers des adresses physiques différentes selon le
processus. Quand Windows charge un exe il construit cette
table (table qui n'est pas la table de saut en mémoire
haute dont j'ai parlé avant, ça tombe sous le sens), donc
à priori différentes pour chaque processus, même si elle
peuvent avoir des points communs, comme le code partagé
des dll.
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:
Je reviens sur la question. Donc oui ici.donc le code sait qu'i est à
l'adresse 10017168h et pas ailleurs.
Mais non là.
Je pense que le mode d'adressage virtuel des Intel 32 bits
t'échappe
Voilà pourquoi une adresse virtuelle donnée va pointer
vers des adresses physiques différentes selon le
processus. Quand Windows charge un exe il construit cette
table (table qui n'est pas la table de saut en mémoire
haute dont j'ai parlé avant, ça tombe sous le sens), donc
à priori différentes pour chaque processus, même si elle
peuvent avoir des points communs, comme le code partagé
des dll.
On répète. Le problème n'a rien à voir avec les adresses
physiques en mémoire réele. C'est un problème de l'adresse dans
l'espace d'adressage du processus. Une fois que la variable
positionnée bien à 0x100217C0, comment est-ce que tu peux
garantir que cette adresse ne sert pas déjà dans d'autres
processus qui veulent utiliser la DLL ?
On répète. Le problème n'a rien à voir avec les adresses
physiques en mémoire réele. C'est un problème de l'adresse dans
l'espace d'adressage du processus. Une fois que la variable
positionnée bien à 0x100217C0, comment est-ce que tu peux
garantir que cette adresse ne sert pas déjà dans d'autres
processus qui veulent utiliser la DLL ?
On répète. Le problème n'a rien à voir avec les adresses
physiques en mémoire réele. C'est un problème de l'adresse dans
l'espace d'adressage du processus. Une fois que la variable
positionnée bien à 0x100217C0, comment est-ce que tu peux
garantir que cette adresse ne sert pas déjà dans d'autres
processus qui veulent utiliser la DLL ?
Et alors. On le sait. (Je le sais très bien, et je suis sûr que
Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à
l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout
le monde corresponde à la même adresse physique pour tout le monde ? Ca
dépend de la table de descripteur propre à chaque processus et que le
système constitue losqu'il lance un exe.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que
Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à
l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout
le monde corresponde à la même adresse physique pour tout le monde ? Ca
dépend de la table de descripteur propre à chaque processus et que le
système constitue losqu'il lance un exe.
Et alors. On le sait. (Je le sais très bien, et je suis sûr que
Jean-Marc le sait aussi.)
Oui, mais chaque processus accédera bien à la même adresse à
l'intérieur de son espace d'adressage.
Mais enfin, pourquoi voulez vous qu'une même adresse virtuelle pour tout
le monde corresponde à la même adresse physique pour tout le monde ? Ca
dépend de la table de descripteur propre à chaque processus et que le
système constitue losqu'il lance un exe.
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
Nan ! J'aime pas le ton de certains intervenants de ce fil, je fais grève.
Alain Gaillard wrote:
Mais ça ne change rien au problème. Que ce soit l'éditeur de
liens classiques qui fasse la rélocation, ou la fonction
LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL
en mémoire, l'adresse doit être 0x10017168. Et que si cette
adresse est déjà prise lorsque le processus charge la DLL, il y
a un petit problème.
Alain Gaillard wrote:
Mais ça ne change rien au problème. Que ce soit l'éditeur de
liens classiques qui fasse la rélocation, ou la fonction
LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL
en mémoire, l'adresse doit être 0x10017168. Et que si cette
adresse est déjà prise lorsque le processus charge la DLL, il y
a un petit problème.
Alain Gaillard wrote:
Mais ça ne change rien au problème. Que ce soit l'éditeur de
liens classiques qui fasse la rélocation, ou la fonction
LoadLibrary de l'OS, le fait reste qu'une fois l'image de la DLL
en mémoire, l'adresse doit être 0x10017168. Et que si cette
adresse est déjà prise lorsque le processus charge la DLL, il y
a un petit problème.
Jean-Marc Bourguet wrote:Tu peux m'expliquer comment travailler avec un x86 en mode
32 bits sans que les adresses soient des déplacements par
rapport à des segments? (Ces segments généralement ont pour
base l'adresse 0 et une limite de 4GB, je veux bien mais ça
ne change rien, s'il n'y pas d'indication explicite de
segment, c'est DS qui est utilisé sauf quand on utilise des
déplacements par raport à (E)BP et (E)SP).
Les processeurs IA-32 possèdent 3 modèles de mémoire.
Le modèle dit "flat" t'autorises un adressage linéaire,
sans segment ni offset lorsque tu accèdes, par exemple à
un octet.
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Jean-Marc Bourguet wrote:
Tu peux m'expliquer comment travailler avec un x86 en mode
32 bits sans que les adresses soient des déplacements par
rapport à des segments? (Ces segments généralement ont pour
base l'adresse 0 et une limite de 4GB, je veux bien mais ça
ne change rien, s'il n'y pas d'indication explicite de
segment, c'est DS qui est utilisé sauf quand on utilise des
déplacements par raport à (E)BP et (E)SP).
Les processeurs IA-32 possèdent 3 modèles de mémoire.
Le modèle dit "flat" t'autorises un adressage linéaire,
sans segment ni offset lorsque tu accèdes, par exemple à
un octet.
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Jean-Marc Bourguet wrote:Tu peux m'expliquer comment travailler avec un x86 en mode
32 bits sans que les adresses soient des déplacements par
rapport à des segments? (Ces segments généralement ont pour
base l'adresse 0 et une limite de 4GB, je veux bien mais ça
ne change rien, s'il n'y pas d'indication explicite de
segment, c'est DS qui est utilisé sauf quand on utilise des
déplacements par raport à (E)BP et (E)SP).
Les processeurs IA-32 possèdent 3 modèles de mémoire.
Le modèle dit "flat" t'autorises un adressage linéaire,
sans segment ni offset lorsque tu accèdes, par exemple à
un octet.
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Bon, on va faire un exemple simple:
J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C.
A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle
$80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle
$80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à
l'adresse virtuelle $80000000 de C, donc comme il y a des
références absolues il doit modifier le code et ne plus le
partager.
Ma foi je pense qu'il va en reloger une des deux
ailleurs. Windows reloge toujours le code qu'il charge à
partir d'une base de chargement. On peut même proposer une
base de chargement via l'éditeur de liens. Si ça convient
au système il l'applique, sinon il en choisit une autre.
Bon, on va faire un exemple simple:
J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C.
A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle
$80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle
$80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à
l'adresse virtuelle $80000000 de C, donc comme il y a des
références absolues il doit modifier le code et ne plus le
partager.
Ma foi je pense qu'il va en reloger une des deux
ailleurs. Windows reloge toujours le code qu'il charge à
partir d'une base de chargement. On peut même proposer une
base de chargement via l'éditeur de liens. Si ça convient
au système il l'applique, sinon il en choisit une autre.
Bon, on va faire un exemple simple:
J'ai deux DLL: LIB1 et LIB2 et trois exécutables A, B, et C.
A utilise LIB1. B utilise LIB2. C utilise LIB1 et LIB2.
Je lance A, Windows mappe LIB1 à l'adresse virtuelle
$80000000 de A.
Je lance B, Windows mappe LIB2 à l'adresse virtuelle
$80000000 de B.
Je lance C, Windows ne peut pas mapper et LIB1 et LIB2 à
l'adresse virtuelle $80000000 de C, donc comme il y a des
références absolues il doit modifier le code et ne plus le
partager.
Ma foi je pense qu'il va en reloger une des deux
ailleurs. Windows reloge toujours le code qu'il charge à
partir d'une base de chargement. On peut même proposer une
base de chargement via l'éditeur de liens. Si ça convient
au système il l'applique, sinon il en choisit une autre.
Dans l'ensemble, ça me semble un bon compromis. Avec un peu de
bol, il arrivera bien à réutiliser l'image la plupart du temps,
sans pour autant payer le coût (important) en temps d'exécution
qu'a la solution Linux, où les données sont « position
independant » aussi. (Dans le cas où la fonction a un
traitement important, évidemment, le temps supplémentaire
d'exécution n'est pas mesurable. Mais avec une petite fonction
comme ceci, le fait qu'elle soit dans un .so pourrait bien
doubler son temps d'exécution.)
Dans l'ensemble, ça me semble un bon compromis. Avec un peu de
bol, il arrivera bien à réutiliser l'image la plupart du temps,
sans pour autant payer le coût (important) en temps d'exécution
qu'a la solution Linux, où les données sont « position
independant » aussi. (Dans le cas où la fonction a un
traitement important, évidemment, le temps supplémentaire
d'exécution n'est pas mesurable. Mais avec une petite fonction
comme ceci, le fait qu'elle soit dans un .so pourrait bien
doubler son temps d'exécution.)
Dans l'ensemble, ça me semble un bon compromis. Avec un peu de
bol, il arrivera bien à réutiliser l'image la plupart du temps,
sans pour autant payer le coût (important) en temps d'exécution
qu'a la solution Linux, où les données sont « position
independant » aussi. (Dans le cas où la fonction a un
traitement important, évidemment, le temps supplémentaire
d'exécution n'est pas mesurable. Mais avec une petite fonction
comme ceci, le fait qu'elle soit dans un .so pourrait bien
doubler son temps d'exécution.)
Jean-Marc Bourguet wrote: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.
C'est ce que j'avais crû aussi, mais c'est bien -fpie (et non
-fpei, qui est effectivement une faute de frappe). C'est -pic
avec Sun CC.
Enfin, quelqu'un qui comprend ma question ? Je commençais à
devenir fou, ne sachant pas comment me rendre clair.
Tout est rélatif. J'ai déjà vu pas mal de processeurs
pires. Où les sauts étaient aux adresses absolues, et non
rélatifs au IP.
Jean-Marc Bourguet wrote:
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.
C'est ce que j'avais crû aussi, mais c'est bien -fpie (et non
-fpei, qui est effectivement une faute de frappe). C'est -pic
avec Sun CC.
Enfin, quelqu'un qui comprend ma question ? Je commençais à
devenir fou, ne sachant pas comment me rendre clair.
Tout est rélatif. J'ai déjà vu pas mal de processeurs
pires. Où les sauts étaient aux adresses absolues, et non
rélatifs au IP.
Jean-Marc Bourguet wrote: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.
C'est ce que j'avais crû aussi, mais c'est bien -fpie (et non
-fpei, qui est effectivement une faute de frappe). C'est -pic
avec Sun CC.
Enfin, quelqu'un qui comprend ma question ? Je commençais à
devenir fou, ne sachant pas comment me rendre clair.
Tout est rélatif. J'ai déjà vu pas mal de processeurs
pires. Où les sauts étaient aux adresses absolues, et non
rélatifs au IP.
Jean-Marc Bourguet wrote:"Arnold McDonald (AMcD)" writes:
Il n'y a aucune référence à un mode flat dans la doc d'intel
pour les 386 et 486 (la dernière à laquelle j'ai eu accès).
Il n'y en a aucune non plus dans les peintures
préhistoriques de la grotte de Gargas. On est en 2006 et
au processuer multi-coeur now hein...
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Ou j'ai mal compris, ou c'est toi. Ces modes ne servent en
rien à étendre l'espace de la mémoire virtuelle mais au
contraire à étendre la mémoire physique. Autrement dit,
rien ne change dans la partie segmentation (qui forme les
adresses virtuelles) mais la partie pagination peut adresser
plus que 32 bits. Pour en profiter dans un processus, il
faudrait revenir à une technique semblable à la fameuse
mémoire paginée LIM -- j'ai retrouvé le troisième laron:
Intel --; peut-être que Windows le permet d'ailleurs.
J'ai pas le temps là, je détaillerai ce soir. On verra
bien qui a mal compris...
Jean-Marc Bourguet wrote:
"Arnold McDonald (AMcD)" <killspammers@free.fr> writes:
Il n'y a aucune référence à un mode flat dans la doc d'intel
pour les 386 et 486 (la dernière à laquelle j'ai eu accès).
Il n'y en a aucune non plus dans les peintures
préhistoriques de la grotte de Gargas. On est en 2006 et
au processuer multi-coeur now hein...
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Ou j'ai mal compris, ou c'est toi. Ces modes ne servent en
rien à étendre l'espace de la mémoire virtuelle mais au
contraire à étendre la mémoire physique. Autrement dit,
rien ne change dans la partie segmentation (qui forme les
adresses virtuelles) mais la partie pagination peut adresser
plus que 32 bits. Pour en profiter dans un processus, il
faudrait revenir à une technique semblable à la fameuse
mémoire paginée LIM -- j'ai retrouvé le troisième laron:
Intel --; peut-être que Windows le permet d'ailleurs.
J'ai pas le temps là, je détaillerai ce soir. On verra
bien qui a mal compris...
Jean-Marc Bourguet wrote:"Arnold McDonald (AMcD)" writes:
Il n'y a aucune référence à un mode flat dans la doc d'intel
pour les 386 et 486 (la dernière à laquelle j'ai eu accès).
Il n'y en a aucune non plus dans les peintures
préhistoriques de la grotte de Gargas. On est en 2006 et
au processuer multi-coeur now hein...
Depuis le P6 et les PAE, PSE et compagnie, tu peux
adresser des segments supérieurs à 4 GB.
Ou j'ai mal compris, ou c'est toi. Ces modes ne servent en
rien à étendre l'espace de la mémoire virtuelle mais au
contraire à étendre la mémoire physique. Autrement dit,
rien ne change dans la partie segmentation (qui forme les
adresses virtuelles) mais la partie pagination peut adresser
plus que 32 bits. Pour en profiter dans un processus, il
faudrait revenir à une technique semblable à la fameuse
mémoire paginée LIM -- j'ai retrouvé le troisième laron:
Intel --; peut-être que Windows le permet d'ailleurs.
J'ai pas le temps là, je détaillerai ce soir. On verra
bien qui a mal compris...
