Programovani - shared libraries na Linuxu

[Pavel Kankovsky]

On Wed, 5 Sep 2001, Martin `MJ' Mares wrote:

> [1]  | 08048000-08049000 r-xp 00000000 03:06 540904     /tmp/test
> [2]  | 08049000-0804a000 rw-p 00000000 03:06 540904     /tmp/test
> [3]  | 40000000-40014000 r-xp 00000000 03:06 34469      /lib/ld-2.2.4.so
> [4]  | 40014000-40015000 rw-p 00013000 03:06 34469      /lib/ld-2.2.4.so
> [5]  | 40015000-40016000 rw-p 00000000 00:00 0
> [6]  | 4001c000-40132000 r-xp 00000000 03:06 34472      /lib/libc-2.2.4.so
> [7]  | 40132000-40138000 rw-p 00115000 03:06 34472      /lib/libc-2.2.4.so
> [8]  | 40138000-4013d000 rw-p 00000000 00:00 0
> [9]  | bfffe000-c0000000 rwxp fffff000 00:00 0
[...]
> [5] je podle vseho pamet alokovana za behu dynamickym linkerem (ten jeste
> nemuze pouzivat normalni malloc(), tudiz si naalokuje svou vlastni stranku
> na data), [8] jsou ostatni malloc()-em alokovane promenne (neni mi ovsem
> jasne, kde se jich vzalo tolik; podezrivam stdio) a [9] zasobnik.

Mensi oprava: [8] je spis z vetsi casti (ne-li uplne) .bss od glibc, nez
dynamicky alokovana pamet -- pokud se neco nezmenilo, tak glibc by male
bloky (a takovych alokaci je asi vetsina) umistovalo za [2] (brk()).  
Ostatne velikost .bss zaokrouhlena na cele stranky je u glibc 2.2 asi tech
5 stranek.

> [1], [3] a [6] jsou urcite sdilene; [5], [8] a [9] urcite nesdilene;
> [2], [4] a [7] by mohly byt sdilene, pokud do nich jeste nikdo nezapsal,
> ale u vetsiny z nich (mimo casti [7]) to neni moc pravdepodobne.
> Celkem tedy 16 stranek potencialne nesdilene pameti po 4KB.

Pohled do /proc/*/statm (posledni cislo "dirty pages"...pozor: nemusi
nutne davat smysl, kdyz se zacne swapovat) odhali, ze ve skutecnosti je
je to asi jen 14 stranek. (Tedy "jen"...stare ZX Spectrum se 48 kily RAMky
by s tim melo problemy... :> )

> >  Jednu z tech knihoven (libkdeui) jsem dokonce rucne kontroloval, nenasbira 
> > se tam ani na 4kB globalnich promennych a podobnych veci, pritom libkdeui 
> > dela rozdil 100kB, takze 96kB z toho jde na vrub tomu, co vyplodi gcc a 
> > binutils. No neni to nadhera ? Pak ze KDE team pise neoptimalizovany kod a 
> > trapaci v ruznych prispevcich vsude mozne trousi blbosti o minimu 256MB na 
> > beh KDE a podobne.
> 
> Ehm, myslim, ze by Vasim nazorum prospelo, kdybyste se nejdrive podival
> (napriklad stejnou metodou, jakou jsem ja pouzil vyse), co tu pamet
> _opravdu_ zabira a pripomenul si, ze existuje i dynamicky alokovana
> pamet a ze na to, aby se pouzila, neni potreba ani explicitne zavolat
> jakoukoliv funkci z prislusne knihovny, nebot (i v gcc, nejen v C++)
> existuji i konstruktory.

Take existuji veci jako .got a .plt, ktere zrovna u toho libkdeui zabiraji
odhadem tam 30 kilo a narozdil od glibc je mala sance, ze by mohly byt
konstantni, protoze nejmene 1000 symbolu v .dynsym je nedefinovanych,
a tudiz bude muset dyn. linker udelat zhruba stejny pocet relokaci.
(I kdyz u toho .got nevim, jestli se nemusi relokovat vzdycky.)

> > nebo jak skvele konstatni je v ELF PIC kodu vec 
> > jako 'const char* const txt[] = { "raz", "dva" };',
> 
> Uznavam, nic moc ... Vite o nejakem lepsim reseni?

V zasade by melo jit udelat neco takoveho:

static const char base[1];
static const char s1[] = "raz";
static const char s2[] = "dva";
static const ptrdiff_t txt_off[] = { s1-base, s2-base };

a misto txt[i] psat (base+txt_off[i]). :)

Jinak se opravdu neda vyhnout absolutnim adresam, ktere nemohou byt
v pripade PIC kodu "konstantni"...at uz je to ELF nebo neni.

(Jina vec je, ze gcc mi na tom stejne drzkuje, ze rozdil sN-base neni
konstantni, coz ale nema tak uplne pravdu.)

> Jen sam urcite ne, ale tomu, ze z 90% sam, bych uz klidne veril :-)
> Nevim, jak StarOffice, ale Mozilla je opravdu priserny bloatware ...
> za vse mluvi jedna veta z ChangeLogu ve stylu "prave jsem usetril
> 400000 alokaci pameti pri startu, coz je asi 20%" :-)

Strasny problem tehle programu spociva v opojeni C++ konstruktory.
Vysledek je ten, ze maji jakasi staticka konstantni data, ktera pri startu
pomoci konstruktoru prezvykaji na jine datove struktury, coz 1. trva
dlouho, 2. sezere strasne moc pameti na neco, co uz v te pameti vlastne
je, akorat se to prelozi do jine formy.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."