GNU bloatware

9.3.2006 13:46 | Přečteno: 1360× | Linux | poslední úprava: 9.3.2006 13:48

Kdysi dávno existovaly toolchainy, která "prostě fungovaly", uměly vše potřebné a nedělaly zbytečné blbosti. Pak nás postihlo GNU, které přineslo zkázu v podobě emacsu a gcc. Ten neuvěřitelný bordel co má gcc v includech je naštěstí viditelný, takže se proti němu občas bojuje, ovšem proti tomu co vyvádí ld jde o slabý odvar. Přeji příjemnou zábavu s čtením map file triviálního executable:

$ more main.c
int main () { return 0; }
$ gcc -Wl,-M main.c 2>map
$ more map

Sice jsem chtěl napsat pouze "bez komentáře", ale neudržím se. Proč na linkování jednoho object file potřebuje GNU ld načíst a použít 13 obj souborů nebo knihoven? Proč je výsledkem linku (po agregaci linkovacím skriptem!) neskutečných 62 sekcí, z toho 34 obsahujících nějaká data, a 28 které se mapují do paměti? Proč je i taková blbost jako inicializace současně implementována třemi nezávislými způsoby (.preinit_array, .init_array, .ctors)? Opravdu je potřeba jen kvůli uložení čísla verze překladače vyplýtvat 3 sekce (.gnu.version , .gnu.version_d, .gnu.version_r)? Proč je debug info uloženo v 23 různých sekcích? Jsou ty lidi vůbec normální?        

Komentáře

[Luboš Luňák]

Protoze vetsinou odpoved je "protoze to je jedno"? Protoze spoustu tohohle diktuje ELF a ne GNU?

> Kdysi dávno existovaly toolchainy, která "prostě fungovaly", uměly vše potřebné a nedělaly zbytečné blbosti.

No jo, zlaty .COM z DOSu, co chtit vic. A uz ani ta nostalgie neni co byvala.

> Proč na linkování jednoho object file potřebuje GNU ld načíst a použít 13 obj souborů nebo knihoven?

Protoze v tom map souboru jsou nektere vypisovane opakovane a tak jich vlastne 13 neni? A i kdyby, vadilo by to vlastne necemu?

> Proč je výsledkem linku (po agregaci linkovacím skriptem!) neskutečných 62 sekcí, z toho 34 obsahujících nějaká data, a 28 které se mapují do paměti?

Protoze ELF soubory se do pameti nemapuji po ELF sekcich, ale po ELF segmentech? Protoze mit extra sekci na kazdou vec je lepsi nez to mit vsechno nahazeno v jedne (jen tak hadam)? Protoze podle 'objdump --headers' ta vysledna binarka tech sekci 62 nema (alespon tady ne)?

> Opravdu je potřeba jen kvůli uložení čísla verze překladače vyplýtvat 3 sekce (.gnu.version , .gnu.version_d, .gnu.version_r)?

Soude podle http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/specialsections.html, nejspis ne, ale ja tomu vlastne nerozumim.

PS: Ne ze bych je chtel zrovna branit, asi bych u neceho takoveho byl posledni a vlastne nadavat bych na GNU toolchain dokazal pekne dlouho, ale alespon by to moje nadavani nebyl takovyhle hrozny blabol.

[zde]

> Protoze vetsinou odpoved je "protoze to je jedno"?

sizeof(Elf32_Shdr) je 40 byte + rekneme 10 byte na nazev v string table. 62 sekcí napd = 3kB napd.

> Protoze spoustu tohohle diktuje ELF a ne GNU?

Neni pravda, ELF je docela rozumny- blbe udelali akorat hashovani symbolu.

> No jo, zlaty .COM z DOSu, co chtit vic. A uz ani ta nostalgie neni co byvala.

??? Mel jsem na mysli 32-bitove kompilatory od Watcomu, Borlandu, Intelu, nebo Microsoftu. Stary dobry OMF s 32-bit rozsirenimi. Jeden OBJ soubor na zacatek, druhy na konec, mezi to co programator racil plus LIBC a bylo vymalovano. Zadne potrhle linker scripty, zadne miliony segmentu a sekci (prestoze OMF je samozrejme umel).

> Protoze v tom map souboru jsou nektere vypisovane opakovane a tak jich vlastne 13 neni? A i kdyby, vadilo by to vlastne necemu?

Dobra, unikatnich je 11. I kdyz odectu CRT1.O, MAIN.O, LIBC.SO a CRTN.O, ktere maji nejaky smysl, a at nezeru tak i LIBGCC.A, porad tam smrdi 6 modulu navic.

> Protoze ELF soubory se do pameti nemapuji po ELF sekcich, ale po ELF segmentech? Protoze mit extra sekci na kazdou vec je lepsi nez to mit vsechno nahazeno v jedne (jen tak hadam)?

ELF header se mapuje cely. Mas pravdu, sekci v A.OUI neni 62, ale jen 30. 62 jich definuje linker script, ale nejaka data sla pouze do 30 z nich. I tak je ale 30 neopodstatnene cislo.

> ale ja tomu vlastne nerozumim.

Nevadi, ja taky ne.

> ale alespon by to moje nadavani nebyl takovyhle hrozny blabol.

Kde si to nadavani muzu precist? Protoze kdyz nebudes nadavat, nikdy se to nezlepsi.

[zde]

> Protoze podle 'objdump --headers' ...

objdump z nejakeho podivneho duvodu nezobrazuje sekce .shstrtab .symtab .strtab a take sekci NULL, prestoze je binarka obsahuje, jak dokazuje readelf --section-headers.