Thema: GCC 4.6.0 ELF Segmente und Symbole

[FlashBurn]

Da wollte ich mich heute mal ransetzen und gucken was man alles an Funktionen/Code für Exceptions braucht und dann musste ich feststellen das der GCC ganz schön viel "Müll" in die Objektdateien packt

Erstmal sind da einige Segmente (bei meinem kleinen Testprogramm von 10 Zeilen, immerhin 11) die ".group" heißen und wo ich keine Ahnung habe was die machen.
Dann erstellt mir der GCC für allenmöglichen "Müll" ein neues Segment, sprich wenn ich mehrere Konstanten habe, dann macht er jedes Mal nen neues Segment ".rodata." und dann der Name der Konstanten. Das gleiche macht er auch mit dem ".text" Segment.

Wie bekomme ich es hin das er gleich alles in ein Segment packt, warum macht das der GCC und wozu sind diese ".group" Segmente da?

Die Dateien zusammen zu linken ist keine Option für mich (ich weiß das die meisten komischen Segmente dann verschwinden, Thema Link-Time-Optimization), da ich keine ausführbare Datei brauche, sondern die Objektdateien!

Edit::

Es handelt sich um C++ Code, falls das nicht richtig rüber gekommen ist (kann natürlich sein, dass das dort normal ist?).

[bluecode]

In der Objektdatei sind erstmal Sektion, keine Segmente. Beim Linken werden dann automatisch die Sektionen, die du für überflüssig hälst, zu Segmenten zusammengefasst (beschrieben durch das Standardlinkerskript, was nichts mit Link-Time-Optimization zu tun hat). Ich nehme an, dass es einen Grund dafür gibt, dass erstmal viele Sektionen erstellt werden, kenne ihn aber nicht, aber bin mir ziemlich sicher, dass man das nicht unterbinden kann.
Wo ist denn überhaupt das Problem mit dem "Müll"?

[FlashBurn]

Was die Sektionen/Segmente betrifft hast du recht, ich hatte auch erst überall Sektionen stehen, habe es dann aber aus irgendeinem Grund in Segmente umgeändert.

Problem ist wie gesagt, dass ich keinen Linker nutze bzw. meinen eigenen nutze und der kann mit den LTO Zeugs nichts anfangen und eigentlich will ich das auch nicht. Der "Müll" macht die Datei größer und verlängert die Zeit die ich zum Parsen der Objektdatei brauche. Und im Moment macht er meine Arbeit, herauszufinden wie Exceptions funktionieren und was ich an Code dazu brauche, auch nicht einfacher.

Ich bin mir ziemlich sicher das diese zusätzlichen Sektionen (".group") etwas mit LTO zutun haben, das für Objekte jedes Mal ne eigene Sektion erstellt wird, wird wahrscheinlich auch was damit zu tun haben und eigentlich sollte man das ja abstellen können. Wenn nicht müsste ich mir ja noch ein Tool schreiben, welches diese Sektionen entfernt und die ganzen anderen entsprechende zusammenfässt

Wem die Bezeichnung "Müll" nicht gefällt, kann es ja auch Overhead nennen.

Edit::

Habe herausbekommen was den "Müll" verursacht, die RTTI, weiß nur noch nicht warum.

[erik.vikinger]

Hallo FlashBurn,

Habe herausbekommen was den "Müll" verursacht, die RTTI, weiß nur noch nicht warum.

Auf RTTI würde ich an Deiner Stelle aber nicht verzichten wollen also lass das Zeugs lieber drin.
Warum der GCC so viele Sektionen erstellt weiß ich auch nicht genau aber ich könnte mir vorstellen das es intern leichter ist immer nur kleine Bereiche auf ein mal betrachten zu müssen, soll sich doch der Linker damit rumplagen aus dem ganzen Kram ein sauberes Executable zu machen. Es gibt aber auch einen Vorteil bei den vielen Sektionen, alles was innerhalb einer Sektion ist kann der Linker nicht verschieben aber die Sektionen untereinander kann der Linker beliebig anordnen so das er z.B. gezielt Daten die oft benutzt werden (weil viele Code-Stellen darauf referenzieren) zusammenpacken um eine hohe Cache-Effizienz zu erreichen. Oder der Linker könnte Konstanten in die Nähe des Codes packen der diese Konstanten verwendet um mit möglichst kleinen Offsets bei der IP-relativen Adressierung aus zu kommen, z.B. bei ARM ist das sehr wichtig da dort solche Offsets nur 12 Bit groß sein können (bei größeren Offsets werden mehrere Befehle benötigt).

Was willst Du eigentlich machen? Willst Du einen eigenen Linker programmieren?


Grüße
Erik

[FlashBurn]

Auf RTTI würde ich an Deiner Stelle aber nicht verzichten wollen also lass das Zeugs lieber drin.

Wozu brauche ich das, vorallem im Kernel? Kostet nur zusätzlichen Speicher für ein Feature was ich nicht nutze.

Was willst Du eigentlich machen? Willst Du einen eigenen Linker programmieren?

Im Endeffekt habe ich schon meinen eigenen Linker bzw. würde ich ihn eher als Loader beschreiben. Er arbeitet halt mit Objektdateien und nicht mit Executeables. Ich nutze das für meinen Kernel, er und alle Module liegen als Objektdateien vor und werden von meinem Bootloader zusammengesetzt.

Edit::

Zumal ich ja Code bräuchte um RTTI im Kernel unterstützen zu können und bis ich den habe, habe ich auch verstanden wie der Code für Exceptions aussehen muss und das kann dauern

[erik.vikinger]

Hallo FlashBurn,

Wozu brauche ich das, vorallem im Kernel? Kostet nur zusätzlichen Speicher für ein Feature was ich nicht nutze.

siehe hier  (auch der folgende Abschnitt ist hierzu interessant)
Auf dynamic_cast und typeid würde ich persönlich nur sehr ungern verzichten.

Im Endeffekt habe ich schon meinen eigenen Linker bzw. würde ich ihn eher als Loader beschreiben. Er arbeitet halt mit Objektdateien und nicht mit Executeables. Ich nutze das für meinen Kernel, er und alle Module liegen als Objektdateien vor und werden von meinem Bootloader zusammengesetzt.

Also wenn Du die Programme als Module laden möchtest um sie dann erst kurz vor dem Starten passend zusammen zu linken (z.B. in Abhängigkeit von der vorgefundenen HW-Konfiguration) dann würde ich die Programme so linken lassen als würden sie noch externe Bibliotheken benutzen (es gäbe dann immer noch unaufgelöste externe Abhängigkeiten und auch noch Publics). Ich weiß zwar nicht ganz genau wie das mit ELF umgesetzt wird aber im Prinzip sind die Executables auf einem normalen Linux-System ja auch nicht wirklich fertig gelinkt sondern benötigen immer noch eine libc o.ä. was dann als externe Bibliothek erst vom Loader im Linux-Kernel dazugelinkt wird so dass das fertig statisch gelinkte Executable erst im Speicher entsteht.


Warum Du am Code für die Exceptions rumspielen willst hab ich auch noch nicht wirklich verstanden. Ich denke die Leute die den gcc entwickeln haben genug Ahnung von dem was sie da machen das man ihnen einfach vertrauen kann, besser als das was im gcc bereits drin ist wird Deine Lösung mit hinreichend hoher Wahrscheinlichkeit auch nicht werden.


Grüße
Erik

[FlashBurn]

Den Link kenne ich schon. Bisher habe ich weder dynamic_cast noch typeid benötigt und bin mir auch sicher das ich ohne auskomme.

Also wenn Du die Programme als Module laden möchtest um sie dann erst kurz vor dem Starten passend zusammen zu linken (z.B. in Abhängigkeit von der vorgefundenen HW-Konfiguration) dann würde ich die Programme so linken lassen als würden sie noch externe Bibliotheken benutzen (es gäbe dann immer noch unaufgelöste externe Abhängigkeiten und auch noch Publics).

Genau das mache ich! Allerdings arbeitet es sich mit Objektdateien einfacher, ansonsten müsste ich halt Relocateables nehmen, aber wimre muss ich dann den Programheader und die Sectionheader parsen und so muss ich einfach nur alle Sections parsen und kann die die zusammen gehören auch zusammen packen.

Warum Du am Code für die Exceptions rumspielen willst hab ich auch noch nicht wirklich verstanden. Ich denke die Leute die den gcc entwickeln haben genug Ahnung von dem was sie da machen das man ihnen einfach vertrauen kann, besser als das was im gcc bereits drin ist wird Deine Lösung mit hinreichend hoher Wahrscheinlichkeit auch nicht werden.

Also ich würde gerne, anstatt den Code von der libstc++ einfach in meinen Kernel zu packen, was eigenes schreiben (man könnte auch fragen warum wir nen eigenen Kernel schreiben, Linux sollte doch gut genug sein ) und dann kommt hinzu das mal welche Exceptions und RTTI in den Linux Kernel gepackt haben. Dabei haben sie festgestellt wie arsch langsam Exceptions eigentlich sind und haben die Zeit im Schnitt auf 1/6 drücken können.
Das Problem an der Implementierung vom GCC ist, dass sie zu allgemein gehalten ist (soll auf allen Architekturen laufen und auch mehrere Sprachen unterstützen) und somit nicht so schnell ist wie sie sein könnte.

[erik.vikinger]

Hallo,

Bisher habe ich weder dynamic_cast noch typeid benötigt und bin mir auch sicher das ich ohne auskomme.

Hm, nagut. Für mich persönlich sind das beides Features die ich in einer OO-Sprache gerade bei komplexen Vererbungshierarchien gerne benutze.

Genau das mache ich!

Dachte ich mir, Du hattest ja schon mal geschrieben das Du Deinen Kernel erst beim Starten durch den Loader passend zur vorgefundenen HW-Konfiguration zusammenlinken möchtest. Das ist aber schon eine recht sportliche Übung.

Kann der Grub nicht auch so was in der Art? Wimre kann Grub auch externe Abhängigkeiten in den ELF-Dateien auflösen und benötigte Zusatzmodule nachladen und dazulinken. Falls ich da nicht völligen Blödsinn schreibe wäre das sicher eine gute Inspirationsquelle.

Allerdings arbeitet es sich mit Objektdateien einfacher, ansonsten müsste ich halt Relocateables nehmen, aber wimre muss ich dann den Programheader und die Sectionheader parsen und so muss ich einfach nur alle Sections parsen und kann die die zusammen gehören auch zusammen packen.

Also da verstehe ich momentan nicht genau was Du willst, ich dachte immer es gibt nur ein ELF-Format und je nach Datei-Typ (Object-File, Library-File oder Executable) werden die von ELF angebotenen Features passend benutzt bzw. kombiniert. Grundsätzlich müsste doch der Aufbau der ELF-Datei vor und nach dem unvollständigen Linken immer noch der selbe sein (oder zumindest sehr ähnlich wenn wir mal das Zusammenfassen vieler Sektionen in wenige Sektionen usw. ignorieren).

.... und dann kommt hinzu das mal welche Exceptions und RTTI in den Linux Kernel gepackt haben. Dabei haben sie festgestellt wie arsch langsam Exceptions eigentlich sind und haben die Zeit im Schnitt auf 1/6 drücken können.
Das Problem an der Implementierung vom GCC ist, dass sie zu allgemein gehalten ist (soll auf allen Architekturen laufen und auch mehrere Sprachen unterstützen) und somit nicht so schnell ist wie sie sein könnte.

Nunja, wie das im gcc genau realisiert ist weiß ich nicht und wenn die zwecks größtmöglicher Portabilität da gewisse Kompromisse gemacht haben dann ist das für Deinen Kernel, der natürlich nur auf einer CPU-Architektur laufen soll, erstmal ziemlich doof. Das Problem was ich da sehe ist das wenn Du das Exceptionhandling (mit Stackunwinding usw.) ändern möchtest das Du dann eventuell schon deutlich weiter vorne im Compiler ansetzen musst und nicht erst beim Linker. Außerdem könnte es ja sein das die nächste gcc-Version da vielleicht was ändert und dann fängt Deine Bastelei wieder von vorne an.

Ich hab vor einiger Zeit mitbekommen das im LLVM-Lager über dieses Thema heftig diskutiert wurde und da wohl auch einige neue Wege beschritten wurden aber genau verfolgt hab ich das auch nicht. Vielleicht könntest Du ja mal über einen Compiler-Wechsel nachdenken (falls beim LLVM wirklich bessere Lösungen vorhanden sind) oder muss es unbedingt der gcc sein?


Grüße
Erik

[FlashBurn]

Für mich persönlich sind das beides Features die ich in einer OO-Sprache gerade bei komplexen Vererbungshierarchien gerne benutze.

Also so komplex soll mein Kernel nicht werden und ist er bisher auch nicht.

Das ist aber schon eine recht sportliche Übung.

Der läuft schon seit 2 oder 3 Jahren und war im Endeffekt das gleiche als ob du nen Loader für die Programme für dein OS schreibst (konnte den meisten Code genau dafür wiederverwenden).

Kann der Grub nicht auch so was in der Art?

Selbst wenn, ich kann und will Grub nicht nutzen. Ich habe meine Memorymap dann doch etwas anders als GRUB aufgebaut und nutze keinen Multiboot-Header zumal ich ja das Zusammenlinken eh selbst machen müsste, weil ich ja nach der vorhandenen HW entscheide welches Modul gelinkt wird.

Das Problem was ich da sehe ist das wenn Du das Exceptionhandling (mit Stackunwinding usw.) ändern möchtest das Du dann eventuell schon deutlich weiter vorne im Compiler ansetzen musst und nicht erst beim Linker.

Da habe ich dann nicht genügend Infos gegeben. Um Exceptionhandling zu unterstützen muss ich "nur" den Stackunwinding-Code, den Code für das DWARF-Format und den Exceptionhandling-Code (throw, catch, rethrow) schreiben. Mit dem Linker hat das nichts mehr zu tun.
Nur bin ich bei dem Versuch zu gucken wie das aussieht auf das Problem gestoßen das mir der GCC ganz schön viele unbekannte Sektionen in meine Objektdatei packt (die ich ja auf die RTTI zurückführen konnte).

Sprich wenn du Exceptions nutzen willst, brauchst du halt die entsprechenden Funktionen (die ich wahrscheinlich relativ einfach kopieren könnte) zu deinem Kernel linken und das sollte soweit funktionieren.

Allerdings wollte ich dann doch ein paar Veränderungen vornehmen, z.B. muss panic() aufgerufen werden, wenn eine Exception nirgends aufgefangen wird und da war irgendetwas was die im GCC Code doppelt machen, das brauche ich auch nicht und dann müssten noch malloc() und free() angepasst werden.

Ich hab vor einiger Zeit mitbekommen das im LLVM-Lager über dieses Thema heftig diskutiert wurde und da wohl auch einige neue Wege beschritten wurden aber genau verfolgt hab ich das auch nicht. Vielleicht könntest Du ja mal über einen Compiler-Wechsel nachdenken (falls beim LLVM wirklich bessere Lösungen vorhanden sind) oder muss es unbedingt der gcc sein?

Ich habe erst gestern LLVM/CLang kompiliert, aber CLang war gleich mal um ein vielfaches langsamer als der gcc bei meinem C-Code. Bei C++ Code habe ich es noch nicht probiert, aber von den Exceptions her nutzen sie das selbe.

Ich bin in sofern an GCC gebunden, das ich spezielle Extensions nutze, die im Kernel schon nicht schlecht sind. Allerdings sollte das meiste von CLang unterstützt werden.

CLang bietet sich dank der Fehlermeldung an. Die sind wirklich um Welten besser als beim GCC!

[erik.vikinger]

Hallo,

Der läuft schon seit 2 oder 3 Jahren und war im Endeffekt das gleiche als ob du nen Loader für die Programme für dein OS schreibst (konnte den meisten Code genau dafür wiederverwenden).

Also ein Loader der ein fertig gelinktes Executable (ohne externe Abhängigkeiten u.ä.) einfach lädt und nur relozieren muss (falls überhaupt) ist IMHO schon ein paar Nummern kleiner als ein Linker, denke ich einfach mal so in meiner segmentierten Naivität. Und beziehe Dich bitte nicht auf meine Plattform, das ist wirklich was ganz anderes.

Selbst wenn, ich kann und will Grub nicht nutzen.

Du sollst den Grub ja auch nicht benutzen (oder vielleicht auch doch aber das klären wir wann anders) sondern Dich einfach mal in dessen Quell-Code ein wenig einlesen, vielleicht findest Du dort ein paar Inspirationen für einige Deiner Probleme beim Linken.

Um Exceptionhandling zu unterstützen muss ich "nur" den Stackunwinding-Code, den Code für das DWARF-Format und den Exceptionhandling-Code (throw, catch, rethrow) schreiben. Mit dem Linker hat das nichts mehr zu tun.

Aha, gut zu wissen, irgendwann werde ich wohl vor dem selben Problem stehen.

Sprich wenn du Exceptions nutzen willst, brauchst du halt die entsprechenden Funktionen (die ich wahrscheinlich relativ einfach kopieren könnte) zu deinem Kernel linken und das sollte soweit funktionieren.

Du benutzt die Du-Form und die Ich-Form etwas chaotisch durcheinander (ich bin verwirrt). Ist das ein Bug, Absicht oder beziehst Du Dich wirklich auch auf meine Plattform? (von letzterem würde ich eher abraten da sich meine Plattform von der die Du benutzt doch sehr erheblich unterscheidet)

aber CLang war gleich mal um ein vielfaches langsamer als der gcc bei meinem C-Code

Meinst Du den Zeitbedarf für das Compilieren oder die Performance des Compilats?

aber von den Exceptions her nutzen sie das selbe

Hm, klingt aber nicht so toll.

CLang bietet sich dank der Fehlermeldung an. Die sind wirklich um Welten besser als beim GCC!

Na wenigstens etwas.


Grüße
Erik

[FlashBurn]

Also ein Loader der ein fertig gelinktes Executable (ohne externe Abhängigkeiten u.ä.) einfach lädt und nur relozieren muss (falls überhaupt) ist IMHO schon ein paar Nummern kleiner als ein Linker

Sobald man (besser als mein "du" ) relozieren muss, ist es aus meiner Sicht auch nichts anderes als Linken. Denn du linkst eine Executeable und meinetwegen Libraries zusammen. Ich spare mir die Executeable.

vielleicht findest Du dort ein paar Inspirationen für einige Deiner Probleme beim Linken.

Ich wüsste jetzt nicht das ich was geschrieben habe, das ich Probleme beim Linken habe Das funktioniert so weit alles.

Du benutzt die Du-Form und die Ich-Form etwas chaotisch durcheinander (ich bin verwirrt).

Sorry, ersetze das "du" durch ein "man".

Meinst Du den Zeitbedarf für das Compilieren oder die Performance des Compilats?

Die Zeit zum Kompilieren (und das war ja eigentlich der Punkt wo LLVM/CLang wesentlich besser sein sollte). Was den erstellten Code betrifft, ist GCC schon noch besser (habe ich nicht gemessen, sondern habe mir den Assembler-Code angeguckt).

Um es mal direkt zu sagen, mein eigentliches Problem, die komischen Symbole und Sektionen, ist ja eigentlich gelöst, aber mich würde schon interessieren warum ich GRUB nutzen sollte? Ich bin der Meinung bei nem Mikrokernel ist GRUB nicht unbedingt das Wahre ist. Außerdem beschränkt mich GRUB ja in meinem Vorhaben.

[FlashBurn]

Ich grabe den Thread mal wieder aus, da die ".group" Sektionen wieder da sind

Sie treten nur auf, wenn ich pure virtual Methoden (kann auch nur virtual sein, da bin ich mir nicht sicher, weil ich es nicht verwende) oder Templates nutze.

Es ist nicht das Problem das ich diese Dateien nicht verarbeiten könnte, aber es ist halt Speicherverschwendung und setzt damit effektiv mein Cachesystem im Bootloader außer Kraft.
Von daher würde ich diese Sektionen gerne loswerden und ich würde auch die vielen unter-Sektionen gerne zusammenfassen.

Eigentlich müsste das doch mit nem Linker-Skript gehen oder (ich will keine executeable, sondern eine Objektdatei erzeugen!)?

Ich habe dann noch solch nette ".text.startup" Sektionen. Wozu sind die gut (ich vermute mal sie haben was mit den globalen statischen Objekten zu tun)? Das gleiche dann nochmal zu ".text.exit", wird wahrscheinlich für die globalen statischen Objekte sein.
Auch interessant sind die read-only Sektionen für meine abgeleiteten Klassen, wo dann die virtuellen Methoden implementiert werden. Eine Sektion für die Basisklasse, mit 2 Relokationen für die __cxa_pure_virtual Funktion und dann noch jeweils eine Sektion für jede abgeleitete Klasse mit auch 2 Relokationen für die beiden implementierten Funktionen.
Wie muss ich mir das dann vorstellen, hat jedes Objekt nen Pointer zu diesen Sektionen damit, der Code weiß, welche Funktion er aufrufen muss?

[FlashBurn]

Ich habe mir jetzt mal nen Linkersckript zusammengebastelt und bin die ".group" Sektionen los, wollte aber gleich auch die Konstruktoren für die globalen statischen Objekte mit reinnehmen, so dass sie automatisch ausgeführt werden (von meinem Code natürlich).

Aber die tauchen aus irgendeinem Grund nicht mehr in der endgültigen Objektdatei auf, in der speziellen Objektdatei schon (die Objektdatei zu der jeweiligen .cpp Datei).

Code: [Auswählen]

SECTIONS
{
.init ALIGN(4) :
{
start_ctors = .;
*(.ctors*)
end_ctors = .;

*(.init*)
*(.text.startup*)
}

.text ALIGN(4) :
{
*(.text*)
}

.rodata ALIGN(4) :
{
*(.rodata*)
}

.data ALIGN(4) :
{
*(.data*)
}

.bss ALIGN(4) :
{
*(.bss*)
}

/DISCARD/ :
{
*(.comment)
*(.dtors*)
*(.group*)
*(.text.exit*)
}
}

Ist an dem Skript irgendwas falsch oder was könnte es noch sein, das die Konstruktoren weg sind (start_ctors und end_ctors haben die gleiche Adresse)?

Edit::

Also das Problem liegt in meinem Bootloader und nicht am Skript. Ich trage die Symbole mit der richtigen Adresse in meinen PatriciaTree ein, aber wenn ich dann alle Symbole auflöse (Relocation), bekommt ich ne falsche und die gleiche Adresse für die beiden Symbole (start_ctors und end_ctors). Was irgendwie komisch daran ist, der Kernel scheint ansonsten trotzdem zu laufen, also scheinen die anderen Symbole alle richtig aufgelöst zu werden.

Edit::

Problem gelöst

War eigentlich ziemlich "einfach", da ich im Bootloader mehrere Module zusammenlinke, die ja alle die beiden Symbole (start_ctors und end_ctors) haben, kann es nur schief gehen, weil die ja alle andere Adressen haben.
Ich habe es jetzt so gelöst, dass ich diese Symbole nicht mehr im Linkerskript erzeuge, sondern das der Bootloader sich den Anfang und das Ende der allgemeinen ctors Sektion (wo alle .ctors aus allen Modulen reinkommen) merkt und die Adressen für die Symbole (start_ctors und end_ctors) einfach in meinen PatriciaTree einfügt. Damit werden jetzt auch endlich die globalen statischen Konstruktoren aufgerufen und ich muss das nicht mehr von Hand machen.