Re: [CPROG] gcc og -PIC

["Erwin S. Andreasen" <sslug@sslug>]

Mark Wrobel <sslug@sslug> writes:

> Men, vil det sige at koden fra biblioteket bliver siddende i
> hukommelsen efter at processen terminere? Således biblioteket er klart
> hvis nu en anden proces senere skulle bruge det?

Implicit, som et side-effekt af hvordan det blev hentet i hukommelsen. 
Når en ELF binær fil (shared object eller et almindeligt program)
åbnes bliver det ikke bare indlæst råt i hukommelsen -- et område
virtuelt hukommelse bliver ved hjælp af mmap() associeret med et
område i filen. Kode-segmentet bliver mmappet med flag som tillader
deling af denne association mellem flere forskellige processer.

Hvis jeg fx kigger på /proc/1264/maps som er listen over de 86 mmaps
som denne xemacs proces har lavet kan jeg se:

08048000-081c7000 r-xp 00000000 03:43 332514     /usr/bin/xemacs-21.4.8-mule

I processens virtuelle adresserum fra 0x08048000 til 0x081c7000
(1568768 bytes) er en del (.text segmentet) af min xemacs binær fil
mappet ind. Det er mappet sådan at området kan læses og eksekveres. 
mmap'en starter på offset 00000000 i den binære fil og kommer fra
inode 332514 på device 03,43 (i hex, det er altså /dev/hdb3).

Hvis en anden proces beder om nogle af de samme sider i den samme fil,
kan de af kernen deles. Siderne ligger i cachen og de bliver ved med
det når programmet afsluttes, så hvis jeg starter og afslutter xemacs
bliver de ikke nødvendigvis fjernet med det samme.

Data fra filen bliver heller ikke hentet med det samme fra disken, men
kun "on-demand". De kan også fjernes fra hukommelsen igen hvis der er
brug for det, de kan jo altid hentes fra disken igen. Det er en
kompliceret sag at finde ud af hvad der er mest effektivt.


> (hvordan tjekker man
> egentlig det på en RH? altså hvad der ligger i hukommelsen)

Jeg er ikke klar over hvordan man kan vise en liste over hvad der
egentlig fysisk er i hukommelsen. Hvis du vil kan du sammenlægge
information fra /proc/*/maps, og jeg lavede engang et script til vores
embedded Linux system hos Eicon som gjorde det, for at finde ud af
hvad det egentlig var vi havde mappet ind i hukommelsen. Men det er
kun de virtuelle mapninger, og du kan ikke se fx hvor meget af de
1568768 ovenover faktisk er i hukommelsen.

Jeg mindes svagt noget om en "rmap" patch som laver en relation mellem
de sider der er i hukommelsen og hvem der ejer dem (der er ellers
normalt kun den anden vej: man kan hvilke sider en proces har mmappet
men ikke hvilke processer har en bestemt side mmappet). Måske giver
den mulighed for en mere nøjagtig eksamination af det forbrugte
hukommelse.

-- 
===============================================================
<sslug@sslug>                           Herlev, Denmark     
<URL:http://www.andreasen.org/>                             <*>   
===============================================================