a fine detail on how DLLs are relocated as the result of a base address collision, and consequences

Raymond

tammikuun 19., 2017

jos DLL on siirrettävä, koska perusosoite konflikti, sitten kuva siirretään, ja koko siirretty DLL on nyt tukena sivun tiedosto.

jos luet kuvauksen tarkemmin, huomaat, että page-tiedosto ei tue aivan koko siirrettyä DLL: ää. Tarkemmin, kaikki sivut, jotka sisälsivät korjauksia laitetaan sivu tiedosto. Jos olet onnekas ja sinulla on sivu ilman korjauksia, niin tuo sivu on edelleen demand-paged kuvasta, koska ydin ei sovellettu mitään korjauksia siihen, ja siksi ei aiheutunut copy-on-write kyseiselle sivulle, joten se on edelleen tukena tiedostojärjestelmän kuva.

yksi näkemistäni argumenteista tarkoituksellisesti aiheuttaa perusosoitteen törmäys on niin, että siirretty DLL kopioidaan page-tiedostoon, mikä on voitto, jos sivu-tiedosto on nopeammalla välineellä kuin DLL. Esimerkiksi, sivu tiedosto voi olla SSD tai (gasp) RAM-asema.

tämä logiikka ei ota huomioon sellaisten sivujen tapausta, joissa ei ole korjauksia. Nämä sivut sivuavat edelleen suoraan alkuperäisestä tiedostosta, mikä on ongelma, jos alkuperäinen tiedosto on hyvin hitaalla levyllä, tai keskipitkällä, joka voi kadota, kuten CD-ROM-asema tai verkkoasema.

onneksi sinun ei tarvitse pelata hauskoja pelejä, joissa on perusosoiteristiriitoja saadaksesi koko DLL: n ladatuksi page-tiedostoon. Käytä sen sijaan /SWAPRUN linker-lippua, jonka avulla voit määrittää moduulin otsikossa, että lataajan tulee kopioida kuva swap-tiedostoon.

Raymond Chen

Follow

Vastaa

Sähköpostiosoitettasi ei julkaista.