Thema: C-Kernel ohne Multiboot

[kevin]

Also bei der Distribution würde ich auf jeden Fall einen Bug aufmachen. Selbst wenn Upstream den Bug fixt, muss der Fix ja noch irgendwie in die Distribution reinkommen.

Zusätzlich noch an die binutils-Mailingliste schreiben ist natürlich auch nicht verkehrt, aber vorher sollte man dann die aktuellste binutils-Version nehmen und selber durchbauen (d.h. bekanntermaßen komplett ohne zusätzliche Patches).

[PNoob]

Zusätzlich noch an die binutils-Mailingliste schreiben ist natürlich auch nicht verkehrt, aber vorher sollte man dann die aktuellste binutils-Version nehmen und selber durchbauen (d.h. bekanntermaßen komplett ohne zusätzliche Patches).

letzteres kannste unter Ubuntu vergessen. ich habs merfach versucht, die neusten binutils und gcc zu bauen, mitten drin bei binutils oder gcc gibts nen Berg Error Meldungen. Ich bin mir nur nicht mehr sicher ob die Binutils auch schon failen oder obs erst gcc ist. eventuell sonst mal ne VM mit einer anderen Disti nehmen zum testen.

PNoob

[Svenska]

Zumal Ubuntu oft an irgendwelchen Sourcen rumpatcht, bevor es dann im Repository landet.

[erik.vikinger]

Hallo,


entschuldigt Bitte meine naive Ungläubigkeit, aber was will man denn an solchen Basis-Tools wie den binutils distributionsspezifisch patchen? Ich bin bis jetzt davon ausgegangen das sowas einfach übernommen wird und fertig. Ich kann mir einfach keine Funktionalität in einem Linker vorstellen die von der konkreten Linux-Distribution abhängt. Ich meine damit nicht irgendwelche Konfigurationsdetails wie bestimmte Library-Pfade oder sowas.
Wird dann als nächstes beim gcc das Target-Parameter-Tripple noch um eine zusätzliche Distributionsangabe erweitert, damit der dann je nach Distribution anderen Code erzeugen kann?


Grüße
Erik

[kevin]

Von distributionsspezifischem Code hat niemand was gesagt. Aber natürlich fixen Distributionen auch Bugs, die entweder upstream erst in der nächsten Version drin sind, deren Lösung im entsprechenden Projekt heftig umstritten ist, die abgestritten und zu einem Problem des Benutzers erklärt werden usw. Es ist doch grad die Aufgabe der Distributionen, mir was stabileres zu bieten als einen beliebigen git-Snapshot. Nur geht halt beim Stabilisieren auch manchmal was in die Hose...

[erik.vikinger]

Hallo,

die entweder upstream erst in der nächsten Version drin sind, deren Lösung im entsprechenden Projekt heftig umstritten ist, die abgestritten und zu einem Problem des Benutzers erklärt werden usw.

Okay, das sind natürlich wichtige/richtige Gründe. Aber von den Basis-Programmen (und dazu zähle ich persönlich auch die binutils) würde ich sowas nicht erwarten und wenn bei einem Bug doch erst mal entschieden/abgestimmt werden muss ob das wirklich ein Bug ist oder nicht eher gewünschtes Verhalten dann sollte die Distribution auch warten bis es eine Entscheidung gibt und eben nicht nen eigenen Fork (zumindest wenn sich die Distribution vorschnell für das andere entscheidet) generieren.

Es ist doch grad die Aufgabe der Distributionen, mir was stabileres zu bieten als einen beliebigen git-Snapshot.

Ich weiß nich aber wenn man "beliebig" gegen "Stable-Release" austauscht ist das schon in etwa das was ich persönlich von einer Distribution erwarte. Meiner Meinung nach gibt es nur wenige wirklich triftige Gründe die es notwendig machen das die Distribution was eigenes pflegt. Beim Kernel kann ich mir sowas vorstellen wenn man z.B. möglichst lange bei einer bestimmten Release bleiben möchte um z.B. Closed-Source-Treiber möglichst lange benutzen zu können dann muss man eben viele Bugfixes (und manchmal auch ein nettes Feature) zurückportieren. Aber auch da sehe ich bei den Basis-Tools, die sich doch auf jedem Linux (und eventuell sogar auch auf einigen Unixen) möglichst überall gleich verhalten sollen, keinen Bedarf nach einer distributionsspezifischen Lösung.


Grüße
Erik

[tiger717]

hab openSUSE 11.4, aber gcc und binutils selber kompilieren? Das überlass ich lieber Richard Stallmann ^^

[kevin]

Sei mal vorsichtig mit solchen Aussagen: Wenn du es mit dem eigenen OS ernst meinst, wirst du gcc und binutils früher oder später selber durchbauen müssen.

[Svenska]

Es ist doch grad die Aufgabe der Distributionen, mir was stabileres zu bieten als einen beliebigen git-Snapshot.

Ich weiß nich aber wenn man "beliebig" gegen "Stable-Release" austauscht ist das schon in etwa das was ich persönlich von einer Distribution erwarte.

Naja, wenn du nahezu ungepatchte Pakete möchtest, solltest du dich bei Slackware umschauen. Das nutzt größtenteils auch die Konfigurationsdateien von Upstream...

Meiner Meinung nach gibt es nur wenige wirklich triftige Gründe die es notwendig machen das die Distribution was eigenes pflegt.

Das fängt bei Namen an (Iceweasel <-> Firefox), geht über die Standardkonfigurationen weiter (z.B. PAM kann man auch einfacher machen) und hört bei irgendwelchen obskuren Bugs auf. Und ja, das betrifft irgendwo fast alle Pakete. Leider.

Gruß,
Svenska

[tiger717]

Hrmpf. Wenn mir binutils und gcc bis dahin nicht den letzten Nerf rauben und ich endlich diese Wrap-around-Funktion zum Laufen kriege. Aber naja, wahrscheinlich heul ich dann schon in einem neuen Thread das Forum mit meinen Problemen voll. Die Welt ist zu kompliziert, aber 13jährige haben bekanntlich auch ein anderes Bild von der Welt...

[Jidder]

Das heißt du bist gar nicht 717 Jahre alt? Mensch, ich wusste doch, dass was faul ist.

[tiger717]

Nein, Riesen-Schildkröten in der OS-Dev Branche wird es nie geben!

[PNoob]

Nein, Riesen-Schildkröten in der OS-Dev Branche wird es nie geben!

woher willst du das Wissen? vielleicht bin ich ja eine

PNoob

[tiger717]

Ich habe jetzt mal meinen Linkerscript voll auskommentiert, aber trotzdem macht ld wieder Zicken, d.h. der Fehler muss mit der Flag (-T kernel.ld) zusammenhängen. Aber kann das wirklich sein? Gibt es vielleicht noch eine zweite kernel.ld, die ich nicht kenne?

[tiger717]

Aha:

http://old.nabble.com/-Bug-ld-12613--New%3A-Undetected-buffer-overflow-occurs-in-ld-when-supplied-with-malformed-file-as-a-linker-script-td31262074.html
http://sourceware.org/bugzilla/show_bug.cgi?id=12613

when *what in hex is greater than 0x7F, the corresponding unsigned integer
value is very large, and hence the octal representation does not fit within 3
bytes of buf, causing the overflow of buf.

E.g. when *what = 0x80; the corresponding unsigned int value is 4294967168,
with corresponding octal value being 37777777600.

Ich nutze des öfteren "unsigned char"-Umwandlungen, vielleicht muss ich den Code noch mal überarbeiten.

[Jidder]

Der Bug hat nichts mit der Verwendung von unsigned char in deinem Code zu tun. Stattdessen glaube ich eher, dass in deinem Linkerskript Umlaute stehen. Die haben dann Werte größer 0x7F und verursachen vermutlich den Fehler.

Ansonsten zeig bitte mal das komplette Skript.

[tiger717]

Ich behelfe mich zurzeit mit ld's Flags (--architecture=i386:i386 --entry=_start --output=elf32-i386 (Ich finde leider kein Kommando, um die Multiboot-Sektion in .text einzubinden, hab deshalb das ganze mal ohne eigene Sektion implentiert)

Mein alter Skript:

Code: [Auswählen]

/*  Bei _start soll die Ausfuehrung losgehen */
ENTRY(_start)
OUTPUT_FORMAT(elf32-i386)
OUTPUT_ARCH(i386:i386)

/*
 * Hier wird festgelegt, in welcher Reihenfolge welche Sektionen in die Binary
 * geschrieben werden sollen
 */
SECTIONS
{
  /*
   * . ist die aktuelle Position in der Datei. Wir wollen den Kernel wie gehabt
   * an 1 MB laden, also muessen wir dort die erste Sektion hinlegen
   */
  . = 0x100000;

  /*
   * Der Multiboot-Header muss zuerst kommen (in den ersten 8 kB).
   * Die Standardsektionen einfach hintereinander weg einbinden.
   */
  .text : {
    *(multiboot)
    *(.text)
  }
  .data ALIGN(4096) : {
    *(.data)
  }
  .rodata ALIGN(4096) : {
    *(.rodata)
  }
  .bss ALIGN(4096) : {
    *(.bss)
  }
}

GRUB gibt Error 28 (Item can't fit into memory). Komisch, eigentlich ist die Datei sogar noch kleiner als zuvor...

EDIT: Ich Depp! Hab glatt -Ttext vergessen ... gleich mal korrigieren.
EDIT2: Ok, vergesst das mit Error 28. Funzt jetzt.