Linker und ungenutzte Symbole

[Karlo (Gast)]

Hallo,

im Laufe der Zeit sammelt sich ja einiges an Codeschnippsel an.
Z.B. eigene itoa-Routinen, Puffer- und Listenverwaltung, Formatierte 
Ausgabe etc...

Wenn ich diesen Code in einer Datei myLib.c sammle und im makefile 
hinzufüge wird ja, soweit ich weiß, das resultierende Objekt-File 
komplett (also als Ganzes) dem ELF-File hinzugelinkt.
Wenn ich aber in meinem Projekt nur eine Funktion aus meiner Lib nutze 
wäre dies ja Speicherverschwendung.

Kann man den Linker (avr-gcc Toolchain) irgendwie dazu überreden, nur 
benötigte Funktionen ins ELF zu übernehmen?
Er sollte ja an und für sich erkennen, dass Symbole existieren die nie 
genutzt werden.

Grüße,
Karlo

[micha54 (Gast)]

Hallo,

der Linker linkt nur einzelne Objektfiles aus einer Library.
Jedes xyz.c erzeugt ein Objektfile, und wenn Du mehrere davon in einer 
gemeinsame Library verpackst, so wird keine Speicher für ungenutzte 
Objektfiles verschwendet.

Gruß,
Michael

[Rufus Τ. F. (rufus)]

Das Stichwort lautet "function-level linking".

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570

ist dazu ganz hilfreich, hier vor allem der Hinweis von Andrew Pinski.

Was Du bislang machst, ist ein stinknormales Sourcefile als "Library" zu 
bezeichnen, aber das ist halt keine.

Würdest Du Deine Funktionen tatsächlich in einer Library unterbringen, 
müsstest Du die Library mit der Kommandozeilenoption -l angeben.

Die Library selbst kann (und sollte) aus je einem Sourcefile für jede 
separat zu nutzende Funktion darin bestehen.

Das erfordert einmalig etwas Disziplin, funktioniert dafür aber auch mit 
jedem noch so alten und noch so eingeschränkten Linker.

[Karlo (Gast)]

Danke Rufus Τ. Firefly, sehr informativer Beitrag.

Vor allem der letzte Beitrag von jwatte ist interessant.
Mir gings ähnlich, ich hatte letztens mit dem GreenHills Compiler zu tun 
und war überrascht dass er mir eine nicht-static Funktion komplett 
wegoptimiert hat.
Davor dachte ich auch (mit meinem gcc - Vorwissen) dass immer komplette 
Objecte gelinkt werden.

Ich werde mir mal link-time-optimization und function-sections zu Gemüte 
führen :-)

Achja, mir ist klar dass ich bei meinem Vorgehen keine "richtige" Lib im 
Sinne des C-Standards habe.
Allerdings hat man eben bei vorkompilierten Libs das Problem der 
Laufzeitkonfiguration.
Statische #defines sind da zu unflexibel.
Und auf einem AVR verursacht sowas natürlich overhead.

[Rufus Τ. F. (rufus)]

Karlo schrieb:
> Achja, mir ist klar dass ich bei meinem Vorgehen keine "richtige" Lib im
> Sinne des C-Standards habe.

Du hast gar keine Library, und solltest daher auch aufhören, Dein 
Konstrukt so zu nennen. Das sorgt nur für unnötige Verwirrung.

[Karlo (Gast)]

Nana, immer mit der Ruhe.
Ich denke ich habe klargestellt dass mir durchaus bewusst ist was eine 
Library im engsten Sinne eigentlich ist.

Ansonsten, du kannst ja schonmal anfangen hier die dutzende von 
Wiki-Seiten zu korrigieren, die von irgendwelchen "UART-Libs" oder 
"Bibliotheken zur Ansteuerung von X" erzählen, wenn dir diese 
Unterscheidung so dermasen wichtig ist.

[Dr. Sommer (Gast)]

Eine Library ist eine Sammlung an Funktionalität, ob die jetzt binär als 
.a oder .o oder .so oder doch als Sourcecode (.c) daherkommt ist auch 
wurst. Unbenutzte Funktionen & Variablen wegoptimieren geht mit 
"-ffunction-sections" und "-fdata-sections" beim compilen & linken, und 
beim Linken zusätzlich "-Wl,--gc-sections". "-flto" zusätzlich beim 
compilen & linken hilft auch nochmal.