🚀 go-pugleaf

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-04-18, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>> Poza tym to jest normalne rozwiązanie w każdym systemie. Żaden 
>> współczesny system nie duplikuje identycznych stron w pamięci.

> Cóż, zawsze twierdziłem że Windows jest przestarzały. ;-P

Bo?
	
>> Bzdurą jest to zdanie: Code has to be relocated after it has been loaded 
>> from disk, making it potentially non-shareable between processes. 
>> Dlaczego pisałem w poprzednim poście.

> Z innych powodów, ale realokacja kodu po załadowaniu go do pamięci to
> teraz standard.  Facet może mieć rację (a może nie, naprawdę nie jest to
> tutaj najistotniejsze).

Nie chodzi o relokację, tylko o to jakoby obecnie miała powodować 
niemożność wpółdzielenia pamięci RAM. Po prostu jeden plik dll podlega 
relokacji tylko przy pierwszym załadowaniu. Gdy ten sam plik dll jest 
ładowany przez kolejną aplikację memory manager współdzieli section 
object z już obliczoną informacją o relokacji. 

>>>> Wirtualny adres pod jakim jest zamapowana 
>>>> biblioteka dll w przestrzeni adresowej danego procesu nie ma nic 
>>>> wspólnego ze współdzieleniem pamięci RAM. To system zarządza zawartością 
>>>> pamięci RAM i niemożliwe jest aby ten sam plik dll był dwukrotnie 
>>>> zamapowany w pamięci RAM jako wykonywalny.
>>
>>> Nie rozumiesz.
>>
>>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode
>>
>>> Position independent code
>>
>>> First, let it be said that there is no such thing as
>>> position-independent code on Windows. The dynamic linker will just
>                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> patiently relocate all dynamic libraries that are not loaded at their
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> preferred base address.
>   ~~~~~~~~~~~~~~~~~~~~~~~
>>
>>> Urocze.  :-)
>>
>> No i? 

> No i Windows.  Pełną gębą.

>> YPB?

> No, nie wiedziałem że w Windowsie murzyn siedzi. ;-)

Memory manager się nazywa.

> BTW - preferred base address dotyczy wyłącznie bibliotek systemowych?
> No bo nie bardzo sobie wyobrażam, żeby w Redmont wiedzieli gdzie lubi
> siedzieć takie libpng. ;-)

W przypadku visual studio jest to dla plików dll zawsze 0x10000000. 
Obecnie dodatkowo domyślnie aktywny jest przełącznik /dynamicbase, który 
powoduje w systemach z aslr w przypadku dll obliczenie nowej losowej 
wartości przy każdym starcie systemu.

-- 
Piotr Borkowski