Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: tiger717 am 22. May 2011, 12:31
-
Hallo Forum,
ich kämpfe nun schon seit längerer Zeit mit Problemen mit einem kleinen Assembler/C-Kernel.
Gleich vorweg: Ich habe kein "echtes" eingebautes Diskettenlaufwerk, sondern ein USB-Teil, und das versteht sich leider mit meiner openSUSE-Installation nicht so gut (scheint generell nicht unterstützt zu werden). Deshalb hab ich mich entschieden, erstmal kein Multiboot zu verwenden. Hab auch schon einen kleinen Asm-Bootsektor geschrieben, der einen kleinen "Hello World"-Kernel lädt. (Funktioniert tadellos) Nun wollte ich einfach mal diesen Kernel in C umsetzen (nur um zu sehen, wie das im Prinzip läuft), aber der verhält sich bockig. Ich vermute, das Problem liegt am Build-Vorgang, denn der Kernel verwendet keinerlei "böse" Funktionen.
Hier der Code:
; boot.asm
[global _start]
[extern init]
_start:
call init
hang:
jmp hang
times 512-($-$$)-2 db 0
dw 0xAA55
#include "kernel.h"
void init(void)
{
printline("Hello World!\0");
}
void printline(char hw[])
{
int i;
char* video = (char*) 0xb8000;
for (i = 0; hw[i] != '\0'; i++) {
video[i * 2] = hw[i];
video[i * 2 + 1] = 0x07;
}
}
#ifndef KERNEL_H
#define KERNEL_H
void main(void);
void printline(char hw[]);
#endif
/* Bei _start soll die Ausfuehrung losgehen */
ENTRY(_start)
OUTPUT_FORMAT(binary)
OUTPUT_ARCH(i386:i386)
SECTIONS
{
. = 0x7E00;
.text : {
*(.text)
}
.rodata : {
*(.rodata)
}
.data : {
*(.data)
}
.bss : {
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}
CC = /usr/bin/gcc
LD = /usr/bin/ld
AS = /usr/bin/nasm
CFLAGS = -Wall -Wextra -Werror -nostdlib -nostartfiles -nodefaultlibs -ffreestanding -c
LDFLAGS = -T kernel.ld
ASFLAGS = -f aout
prog:
$(AS) $(ASFLAGS) -o a.out boot.asm
$(CC) $(CFLAGS) -o b.out kernel.c
$(LD) $(LDFLAGS) -o kernel.img a.out b.out
hexdump kernel.img
init:
umount /dev/sda2
ntfs-3g /dev/sda2 /mnt/windata
clean:
rm a.out
rm b.out
rm kernel.img
rm *~
.PHONY: clean
Ich hoffe doch, das mein Anfängerfehler nicht zu gravierend ist.
P.S.: Bei Bedarf kann ich auch den Hexdump anfügen!
-
Dein Fehler liegt darin, dass, wenn du den code so verwendest, ohne anderen code meine ich, du gcc 32 bit code erstellen lässt, du aber beim starten noch im 16 bit, so genannten real mode, modus bist.
das heißt für dich jetzt, du musst einen bootloader schreiben, der in den protected mode springt (32 bit modus) und dann deine c funktion aufruft (von einem kernel würde ich noch nicht sprechen, aber das ist haarspalterei).
besonders würde ich dir die tutorial reihe aus der wiki empfehlen, da wir auch erklärt, wie du einen c-kernel aufsetzt. ich glaube sogar, dass es auch drinsteht, wie du einen c-kernel ohne grub erstellst.
mfg
chris
-
irgendsowas hab ich mir schon gedacht...
gibt es denn keine gcc flag, um 16bit code zu erstellen?
thx
tiger717
P.S.: Ja, ich weiß schon was Real Mode usw ist. (ich les schon seit ca einem Jahr die Artikel hier, es wundert mich, dass ich noch keinen 2.Windows programmiert habe...) Allerdings bin ich halt kein C-Guru (und werde es niemals sein. Assembler ist doch die schönere Sprache ;) )
-
ich verweise mal kurz auf diesen beitrag [Haltbarkeitsdatum überschritten]
mfg
-
Wenn man GCC 16-Bit Code erzeugen lässt, ist das Problem, dass Offsets größer als 64KB immer noch nicht möglich sind. Also kommst du z.B. an den Grafikspeicher für Textausgabe nicht ran, weil 0xb8000 zu groß ist.
-
Hallo,
ich verweise mal kurz auf diesen beitrag [gefährlicher Link entfernt]
Der dort gemachte Tipp ist nur unter ganz speziellen Voraussetzungen einsetzbar. Vor allem funktioniert das nicht wenn externe Funktionen aufgerufen werden die selber in 32 Bit verfasst sind. Des weiteren geht der gcc immer implizit von Flat-Memory aus und das trifft ja auf den Real-Mode nicht zu. Dieser Tipp kann eventuell in speziellen Situationen funktionieren aber das ist kein generischer Weg um den gcc Real-Mode-Code erzeugen zu lassen!
Ich würde ja fast vorschlagen wollen den alten Beitrag zu löschen aber das wäre IMHO nicht im Sinne eines Forums so das ich darum Bitte da eine Warnung drunter zu setzen (am besten ohne das der Beitrag im Board wieder nach oben kommt).
Grüße
Erik
-
Ich finde das etwas übertrieben.
-
hab jetzt mein bootloader um den Pmode-init teil erweitert (inzwischen als 2-Stage, code war mit 800 Bytes zu groß). Allerdings gibt es ein neues Problem: der Linker mag mich nicht und fügt den Kernel nicht ein.
; boot.asm
[global _start]
[extern pmode]
[BITS 16]
[section .text]
_start:
call pmode
hang:
jmp hang
times 512-($-$$)-2 db 0
dw 0xAA55
; boot.asm
[global pmode]
[extern init]
[BITS 16]
[section .text]
pmode:
cli ; Interrupts ausschalten
lgdt [gdtr] ; GDT Pointer laden
mov eax,cr0 ; In PMode wechseln, indem das niedrigste
or al,1 ; Steuerungsbit von cr0 geändert wird
mov cr0,eax ; muss über Umweg über ein anderes Register gemacht werden
jmp codesel:PMode ; FarJump zu einer 32-Bit PMode Funktion
[BITS 32]
PMode:
mov ax,datasel ; Segmentregister laden
mov ds,ax
mov ss,ax
mov esp,0x90000 ; Stack aufsetzen
call init
hang:
jmp hang
[section .data]
gdtr: ; Desktiptortabelle
dw gdt_end-gdt-1 ; Limit
dd gdt ; Basisadresse
gdt:
dd 0,0 ; Null-Deskriptor
codesel equ $-gdt
dw 0xFFFF ; Segmentgrösse 0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x9A ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgrösse 16...19
db 0x00 ; Segmentadresse 24..31
datasel equ $-gdt
dw 0xFFFF ; Segmentgrösse 0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x92 ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgrösse 16...19
db 0x00 ; Segmentadresse 24..31
gdt_end:
-
Gleich vorweg: Ich habe kein "echtes" eingebautes Diskettenlaufwerk, sondern ein USB-Teil, und das versteht sich leider mit meiner openSUSE-Installation nicht so gut (scheint generell nicht unterstützt zu werden). Deshalb hab ich mich entschieden, erstmal kein Multiboot zu verwenden.
Muss ich das verstehen? Wieso kannst du ohne funktionierendes Floppylaufwerk einen handgebastelten Bootloader laden, aber keinen GRUB? Vorteil von Multiboot wäre auch noch, dass du den Kernel da einfach (mit dem für Linux sowieso vorhandenen GRUB) von der Platte booten kannst, ohne den MBR zu überschreiben.
-
hab jetzt mein bootloader um den Pmode-init teil erweitert (inzwischen als 2-Stage, code war mit 800 Bytes zu groß). Allerdings gibt es ein neues Problem: der Linker mag mich nicht und fügt den Kernel nicht ein.
; boot.asm
[global _start]
[extern pmode]
[BITS 16]
[section .text]
_start:
call pmode
hang:
jmp hang
times 512-($-$$)-2 db 0
dw 0xAA55
Nach diesem Stück Code sind die 512 Bytes Bootsektor zu Ende, die das BIOS für dich lädt. Der Rest von deinem Kernel/Bootloader landet also nie im Speicher und das call pmode springt irgendwo in einen undefinierten Bereich.
-
Gleich vorweg: Ich habe kein "echtes" eingebautes Diskettenlaufwerk, sondern ein USB-Teil, und das versteht sich leider mit meiner openSUSE-Installation nicht so gut (scheint generell nicht unterstützt zu werden). Deshalb hab ich mich entschieden, erstmal kein Multiboot zu verwenden.
Muss ich das verstehen? Wieso kannst du ohne funktionierendes Floppylaufwerk einen handgebastelten Bootloader laden, aber keinen GRUB? Vorteil von Multiboot wäre auch noch, dass du den Kernel da einfach (mit dem für Linux sowieso vorhandenen "GRUB) von der Platte booten kannst, ohne den MBR zu überschreiben.
openSUSE erkennt das Diskettenlaufwerk nicht (einfach mal nach "opensuse usb floppy" googlen). Ich vermute, dass GRUB meinen Code nicht erkennt (ist ja beides auf unixoider Basis). Das BIOS erkennt den Bootloader tadellos.
hab jetzt mein bootloader um den Pmode-init teil erweitert (inzwischen als 2-Stage, code war mit 800 Bytes zu groß). Allerdings gibt es ein neues Problem: der Linker mag mich nicht und fügt den Kernel nicht ein.
; boot.asm
[global _start]
[extern pmode]
[BITS 16]
[section .text]
_start:
call pmode
hang:
jmp hang
times 512-($-$$)-2 db 0
dw 0xAA55
Nach diesem Stück Code sind die 512 Bytes Bootsektor zu Ende, die das BIOS für dich lädt. Der Rest von deinem Kernel/Bootloader landet also nie im Speicher und das call pmode springt irgendwo in einen undefinierten Bereich.
Ja,das stimmt tatsächlich. Aber trotzdem, beim Hexdump erscheint der C-Kernel überhaupt nicht:
0000000 fde8 e901 fffd 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 0ffa 1601 8098 200f 0cc0 0f01 c022 13ea
0000210 0880 6600 10b8 8e00 8ed8 bcd0 0000 0009
0000220 07e8 0000 e900 fffb ffff 9090 8955 83e5
0000230 18ec 04c7 8a24 0080 e800 0002 0000 c3c9
0000240 8955 83e5 10ec 45c7 00f8 0b80 c700 fc45
0000250 0000 0000 25eb 458b 01fc 03c0 f845 558b
0000260 03fc 0855 b60f 8812 8b10 fc45 c001 c083
0000270 0301 f845 00c6 8307 fc45 8b01 fc45 4503
0000280 0f08 00b6 c084 ce75 c3c9 6548 6c6c 206f
0000290 6f57 6c72 2164 0000 0017 809e 0000 0000
00002a0 0000 0000 0000 ffff 0000 9a00 00cf ffff
00002b0 0000 9200 00cf 9090
00002b8
-
Moin
vermute, dass GRUB meinen Code nicht erkennt (ist ja beides auf unixoider Basis). Das BIOS erkennt den Bootloader tadellos.
Vermutest du das nur oder hast du Grub schon getestet? Normalerweise müsste GRUB auch mit USB Diskettenlaufwerken gehen.
Kannst du von deinem USB Diskettenlaufwerk booten?
PNoob
-
Moin
vermute, dass GRUB meinen Code nicht erkennt (ist ja beides auf unixoider Basis). Das BIOS erkennt den Bootloader tadellos.
Vermutest du das nur oder hast du Grub schon getestet? Normalerweise müsste GRUB auch mit USB Diskettenlaufwerken gehen.
Kannst du von deinem USB Diskettenlaufwerk booten?
PNoob
Hast du etwa ein USB-Diskettenlaufwerk? Die Sache ist die: Mein BIOS erkennt das Laufwerk (gaaaanz sicher), aber Linux will nie etwas davon gehört haben (sagt nicht mal sowas wie "unknown device"). Außerdem: Ich will hier nur mal testen, wie ich ASM+C gut kombinieren kann. Im späteren OS werd ich dann auch wahrscheinlich Multiboot implentieren. Das Problem liegt ja hier nicht am eigentl. Bootvorgang, sondern am Linker (bzw. Compiler). Wie schon gesagt, will dieser meinen Kernel nicht hinzufügen.
-
Mir ist gerade aufgefallen, dass wenn ich die Linker-Zeile
. = 0x7e00;durch
. = 0x100000;ersetze, ich folgende Fehlermeldung erhalte:
a.out:a.out:(.text+0x9): relocation truncated to fit: 16 against `.text'
a.out:a.out:(.text+0x1e): relocation truncated to fit: 16 against `.text'
b.out:b.out:(.text+0x4): relocation truncated to fit: 16 against `.data'
b.out:b.out:(.text+0xf): relocation truncated to fit: 16 against `.text'
Dass sind jeweils Zeilen mit Speicherzugriffen.
-
0000000 fde8 e901 fffd 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 0ffa 1601 8098 200f 0cc0 0f01 c022 13ea
0000210 0880 6600 10b8 8e00 8ed8 bcd0 0000 0009
0000220 07e8 0000 e900 fffb ffff 9090 8955 83e5
0000230 18ec 04c7 8a24 0080 e800 0002 0000 c3c9
0000240 8955 83e5 10ec 45c7 00f8 0b80 c700 fc45
0000250 0000 0000 25eb 458b 01fc 03c0 f845 558b
0000260 03fc 0855 b60f 8812 8b10 fc45 c001 c083
0000270 0301 f845 00c6 8307 fc45 8b01 fc45 4503
0000280 0f08 00b6 c084 ce75 c3c9 6548 6c6c 206f
0000290 6f57 6c72 2164 0000 0017 809e 0000 0000
00002a0 0000 0000 0000 ffff 0000 9a00 00cf ffff
00002b0 0000 9200 00cf 9090
Das fett markierte ist der Code aus deiner kernel.c. Ist alles da. (Den Kernel in den Bootloader zu linken ist freilich Blödsinn und führt zu nichts funktionierendem, aber das ist ein anderes Problem)
Ach, und GRUB benutzt natürlich nicht den Linuxtreiber, sondern int 13h, also den BIOS-Treiber. Wenn das BIOS mit deinem Floppy zurechtkommt, dann müsste GRUB das auch benutzen können.
-
Ich vermute, dass GRUB meinen Code nicht erkennt (ist ja beides auf unixoider Basis).
GRUB ist nicht Linux und nutzt auch nicht den gleichen Code. Wenn dir GRUB nicht gefällt, kannst du auch SYSLINUX benutzen, der kann (mit dem Modul mboot.c32) auch Multibootkernel laden.
Wenn dein Linux das Diskettenlaufwerk nicht erkennt, das BIOS aber schon - wie schreibst du denn dann den Kernel auf die Diskette? Irgendwas klingt da komisch.
Meine Empfehlung wäre übrigens, dass du mehr Arbeit in das Booten von Multibootkerneln steckst und weniger in den eigenen Bootloader. Das erspart dir richtig viel Arbeit und Ärger und ist später, wenn der Kernel mehr kann, wesentlich flexibler - du brauchst nicht für jedes mögliche Bootmedium einen neuen Bootloader.
Gruß,
Svenska
-
Nen eigenen Bootloader zu schreiben ist wie Svenska schon sagte Mist. Und testen wie Man C und ASM gut verbinden kann, musst du noch früh genug. Spätestens bei den interrupts musst du asm nehmen und bei jedem c kernel müssen so ein paar kleine zeilen asm her, die den stack einrichten. Also asm wird dich auch wenn du in C schreibst nie ganz loslassen.
PNoob
-
Hallo,
Also ich hab auch so ein schickes USB-Floppy-Laufwerk und das funktioniert prima. Das BIOS kann davon booten (ich habs mit DOS und MenuetOS ausprobiert) und es wird auch von Windows und Linux anstandslos erkannt und benutzt. Was ich mir als Problem aber vorstellen kann ist wenn das Laufwerk schon beim Booten dran steckt und das BIOS dafür irgendeinen Legacy-Mode aktiviert (damit es eben über Int 13h erreichbar ist) und dann das richtige OS nicht mehr so einfach ran kommt. Normalerweise stecke ich das USB-Floppy-Laufwerk erst an wenn das richtige OS komplett hochgefahren ist (damit da nicht das BIOS seine SMM-Finger im Spiel hat), außer natürlich ich will von der Floppy booten dann stecke ich das Laufwerk schon vor dem Einschalten/Reset an.
Also asm wird dich auch wenn du in C schreibst nie ganz loslassen.
Jetzt mach dem armen Kerl doch nicht noch mehr Angst!
Spätestens wenn echte User-Mode-Programme kommen sollen wird auch eine eigene crt0.asm fällig werden. ;)
Grüße
Erik
-
Hallo
P.S.: Ja, ich weiß schon was Real Mode usw ist. (ich les schon seit ca einem Jahr die Artikel hier, es wundert mich, dass ich noch keinen 2.Windows programmiert habe...) Allerdings bin ich halt kein C-Guru (und werde es niemals sein. Assembler ist doch die schönere Sprache ;) )
Als Build-Vorgang mach ich erst den ganzen Make-Kram in Linux -> Reboot auf Windows, Rawwrite anschmeißen -> Reboot, Fleißig [F8] drücken und mein Floppy auswählen
(Ich weiß, dass es kompliziert ist, dass braucht mir keiner zu sagen)
Aber warum kann ich den Kernel nicht extern haben? Vielleicht, wenn ich die 2.Stage in eine eigene Sektion packe?
-
Hallo,
(Ich weiß, dass es kompliziert ist, dass braucht mir keiner zu sagen)
Das ist nicht nur kompliziert sondern oberumständlich. Ich kann mir einfach nicht vorstellen das es da keinen einfacheren Weg geben soll. Was zeigt den unter Linux lsusb an?
Aber warum kann ich den Kernel nicht extern haben? Vielleicht, wenn ich die 2.Stage in eine eigene Sektion packe?
Wenn Du den Kernel extern, also nicht als Teil des Boot-Loaders, haben willst dann muss Dein Kernel ein Format haben das Dein Boot-Loader versteht. Mit dem was es da alles zu beachten gibt und welche Möglichkeiten da verfügbar sind könnte man die halbe Forumsdatenbank zutexten, deswegen kurz und schmerzlos: Mach den Kernel als ELF und nimm GRUB!
Grüße
Erik
-
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 058f:6360 Alcor Micro Corp. Multimedia Card Reader
Bus 002 Device 003: ID 13d3:3306 IMC Networks WLAN [RTL8191S]
Bus 004 Device 002: ID 046d:c219 Logitech, Inc. Cordless RumblePad 2
Bus 004 Device 003: ID 045e:009d Microsoft Corp. Wireless Optical Desktop 3.0
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Aber siehe hier: http://www.linux-club.de/viewtopic.php?f=61&t=31792 (http://www.linux-club.de/viewtopic.php?f=61&t=31792)
Das ist momentan leider bei allen Linux Versionen so, jedenfalls wenn es überhaupt erkannt wird.
Ich habe hier ein externes USB Floppy (NEC UF0002) und das wird entweder gar nicht oder immer 8 mal eingebunden.
Getestet mit SuSE 9.2, Ubuntu 5.04, Kanotix BH8 + 2005/1.
Bei Ubuntu 4.10 kommt 'ne Fehlermeldung wegen angeblich ungültiger Partitionstabelle!
Ich vermute das es damit zusammenhängt, das es als SCSI Gerät angesprochen wird und auf alle 8 möglichen Geräteadressen antwortet.
-
Hallo,
mein USB-Diskettenlaufwerk wird ebenfalls als SCSI-Laufwerk (sg0, /dev/sdc) erkannt, und taucht dann zweimal in meinem XFCE auf. Einmal als "Diskettenlaufwerk", einmal mit dem Label der eingelegten Diskette; der zweite Eintrag verschwindet, wenn ich die Diskette herausnehme und taucht wieder auf, wenn ich eine einlege. Ist ein Doublespeed Diskettenlaufwerk von Sony.
Ansonsten, wie Erik schon schrieb, dürfte es eher funktionieren, wenn du das Laufwerk nach dem Booten einsteckst. Möglicherweise kannst du im BIOS "USB Legacy Support" abschalten, dann dürfte das Laufwerk auch unter Linux funktionieren (aber du kannst dann nicht mehr davon booten, ohne es zurückzustellen).
Schließlich bleibt noch der Rat, deinen Kernel als ELF zu bauen, einen wohlbekannten Bootloader zu verwenden und hauptsächlich im Emulator zu testen. An das reale System brauchst du erst rangehen, wenn du dich mit Hardware auseinandersetzen möchtest, die nicht emuliert wird - und um Meilensteine zu testen.
Gruß,
Svenska
-
Hallo,
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 058f:6360 Alcor Micro Corp. Multimedia Card Reader
Bus 002 Device 003: ID 13d3:3306 IMC Networks WLAN [RTL8191S]
Bus 004 Device 002: ID 046d:c219 Logitech, Inc. Cordless RumblePad 2
Bus 004 Device 003: ID 045e:009d Microsoft Corp. Wireless Optical Desktop 3.0
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Da is ja gar kein Floppy-Laufwerk dabei, könnte vielleicht doch ein Problem mit einer BIOS-Legacy-Funktion sein. Prüfe doch mal den Port-Status aller Down-Stream-Ports von allen (Root-)Hubs nach, vielleicht findet sich da irgendein Hinweis, möglicherweise unterstützen moderne USB-Host-Controller den Legacy-Status nicht nur als ganzes sondern auch für individuelle Root-Hub-Ports. Vielleicht steht einer dieser Ports auf "Legacy" o.ä. dann weißt Du zumindest wo Du weiter suchen musst. Ich könnte mir durchaus vorstellen das sich Linux bloß nicht traut das USB-Device dem BIOS zu entreißen aber doch sieht das da eines vorhanden ist. Ansonsten könnte Dir hier vielleicht unser USB-Profi noch einen Tipp geben.
Aber siehe hier: http://www.linux-club.de/viewtopic.php?f=61&t=31792 (http://www.linux-club.de/viewtopic.php?f=61&t=31792)
Ich glaube nicht dass das mit Deinem Problem zusammen hängt. Suse 9 und Ubuntu 4/5 sind doch schon lange Geschichte. Gab es damals überhaupt schon den 2.6er Kernel?
Zum Thema Boot-Loader: der Vorteil von GRUB und den anderen etablierten Boot-Loadern ist nicht nur der das die eventuell weniger Probleme machen sondern liegt auch darin das man Dir hier (oder auch anderswo) eher helfen kann falls doch mal ein Problem auftaucht. Und wenn Du Deinen Kernel wirklich auf Deinem aktuellen PC testen willst dann lege ihn doch einfach mit nach /boot/ und erstelle einen passenden Eintrag im Boot-Menü (solange der Kernel noch nicht so weit ist das er einen eigenen HDD-Treiber enthält besteht doch für Dein System noch keine Gefahr).
Grüße
Erik
-
Hallo, ich habe jetzt das FDD erst nach dem Booten angesteckt, und jetzt funktioniert es! (Wird als sdf eingebunden)
Muß jetzt noch mal über mein GRUB-Image schauen, ich glaub, da ist was faul...
-
Suse 9 und Ubuntu 4/5 sind doch schon lange Geschichte. Gab es damals überhaupt schon den 2.6er Kernel?
Ja, 2.6.0 ist schon sehr lange her. (Hm, Wikipedia sagt Ende 2003, ich hätte eher auf Mitte 2002 getippt. Na gut.)
-
Hallo nochmal,
ich habe jetzt brav nach Tutorial ein GRUB-Image erstellt, doch beim Auswählen des Kernels (beim Booten) sagt er mir, er erkenne das Format nicht (Error 13). Ich habe OUTPUT_FORMAT(elf32-i386) auch im Linkerscript drinne.
thx
tiger717
-
Das heißt in der Regel, dass du keinen gültigen Multiboot-Header in den ersten 8k der Datei hast. Du kannst ihn mal mit mbchk prüfen.
-
Danke, funktioniert jetzt!
-
Du scheinst irgendwie nicht richtig das Wiki zu lesen, sonst wüsstest du, was Emulatoren sind und warum einen eigenen Bootloader schreiben Mist ist.
Denn da braucht's dann kein USB-Floppy-Laufwerk und weniger Diskettenfrickelei :)
-
Danke für den konstruktiven Beitrag, Hartmut. :roll:
Und auch wenn man einen Emulator benutzt, will man sein OS von Zeit zu Zeit auf echter Hardware testen.
-
Hallo,
trotz allem würde ich diesen Thread aber doch als Erfolgsstory für GRUB werten. Von "Nix geht" zu "funktioniert jetzt" in so kurzer Zeit ist doch mal ein perfektes Beispiel. Vielleicht sollte man diesen Thread ja im Artikel "Warum wir GRUB empfehlen" verlinken. ;)
Und auch wenn man einen Emulator benutzt, will man sein OS von Zeit zu Zeit auf echter Hardware testen.
Ein zu wahres Wort!
Grüße
Erik
-
Du scheinst irgendwie nicht richtig das Wiki zu lesen, sonst wüsstest du, was Emulatoren sind und warum einen eigenen Bootloader schreiben Mist ist.
Das liegt wohl an dem Ärger mit Emulatoren, den es unter Linux gibt. Bochs will eine libglitz.so.1, und bei qemu haben die wohl vergessen, was Ausführbares beizulegen (oder hab ich mir da den Sourcecode geladen?)
Und mit dem Bootloader usw.: Ich hab halt überhaupt keine praktische Erfahrung, und ich muss doch sagen, dass wenn z.B. Jutta (Name von der Redaktion geändert), eine mehr oder weniger erfahrene Programmiererin, (zufällig) auf das Wiki kommt, doch von den Tutorials erschlagen wird. Es gibt ja mindestens [Übertriebene Aussage]10 Tutorials[/Übertriebene Aussage], die ein einfaches OS (na gut, Kernel, Bootsektor, schlagt euch meinetwegen die Köpfe darüber ein) beschreiben.
-
Unter Linux willst du einfach den Paketmanager deiner Distribution benutzen. Ist ja nicht wie bei armen Leuten oder Windows, dass man sich selber drum kümmern muss, wo man es herbekommt.
-
Also unter Linux hab ich bisher keine Probleme mit bochs qemu oder VirtualBox gehabt. von meinem selbsgebautem qemu mal abgesehen, der irgendwie keine GUI hatte. Aber die Versionen von den Paketmanagern funktionieren einwandfrei.
PNoob
-
Welches Repo enthält denn bochs? Muss ich gleich mal nachschauen!
-
Hallo,
Welches Repo enthält denn bochs?
Jenes welches zu der von Dir benutzten Distribution gehört. Falls in den offiziellen Distribution-Repositories kein Bochs zu finden ist solltest Du eventuell über den Wechsel der Distribution nachdenken, aber ich bin mir sicher dass das nicht nötig ist.
Was ist jetzt eigentlich aus Deinem USB-Problem geworden? Hast Du da weiter nachgeforscht oder bist Du einfach nur zufrieden damit das es jetzt geht? ;)
Grüße
Erik
-
Ich bin mir nicht sicher, was genau die Erlösung gebracht hat, aber ich denke mal, das Floppy-erst-nach-boot-einstecken hat dann geholfen.
P.S.: Der Luxus der Paketverwaltung gegenüber Windows ist doch immer wieder beeindruckend!
-
Hallo,
aber ich denke mal, das Floppy-erst-nach-boot-einstecken hat dann geholfen.
Ja, das stand auch völlig außer Frage. Ich vermute mal da macht irgendeine Legacy-Emulator-Funktionalität des BIOS ein paar Probleme. Meine Frage zielte aber eher darauf ab ob Du da nun noch etwas weiter geforscht hast (und vielleicht noch ein paar nützliche Infos für die Allgemeinheit bieten kannst) oder ob Du Dich mit der Behelfslösung einfach zufrieden gibst.
Der Luxus der Paketverwaltung gegenüber Windows ist doch immer wieder beeindruckend!
Ja, stimmt schon. Ist irgendwie merkwürdig das so eine risige Firma wie Microsoft es nicht schafft dem auch nur etwas annähernd ähnliches entgegen zu stellen. Dabei gibt es doch sowas tolles wie Paketmanager schon seit so vielen Jahren.
Grüße
Erik
-
Moin
Der Luxus der Paketverwaltung gegenüber Windows ist doch immer wieder beeindruckend!
Ja, stimmt schon. Ist irgendwie merkwürdig das so eine risige Firma wie Microsoft es nicht schafft dem auch nur etwas annähernd ähnliches entgegen zu stellen. Dabei gibt es doch sowas tolles wie Paketmanager schon seit so vielen Jahren.
Mit Windows 8 kommt nen App Store für Windows, das ist dann ein Paketmanager im Microsoft style ;)
PNoob
-
aber ich denke mal, das Floppy-erst-nach-boot-einstecken hat dann geholfen.
Ja, das stand auch völlig außer Frage. Ich vermute mal da macht irgendeine Legacy-Emulator-Funktionalität des BIOS ein paar Probleme. Meine Frage zielte aber eher darauf ab ob Du da nun noch etwas weiter geforscht hast (und vielleicht noch ein paar nützliche Infos für die Allgemeinheit bieten kannst) oder ob Du Dich mit der Behelfslösung einfach zufrieden gibst.
Mit solchen Lowlevel-Hardware-Sachen bin ich nicht wirklich gut aus, und die Allgemeinheit guckt Filme von Blu-Ray-Discs (tatsächlich steckt doch schon was wares dahinter, mein Image ist 1,5 MB groß, die Diskette hat 1,44 MB (liegt wahrscheinlich an der Interpretierung der Vorzeichen (1 Mibibyte = 1024 KB)). Hoffentlich bleibt noch Zeit, bis ich mit meinem selbstgebastelten HDD-Treiber meine Festplatten zerschießen muss. (Zum Glück hab ich 2 Stück)
-
Die 1,44 MB auf Disketten sind noch ein komischeres Konstrukt als die übliche Verwirrung, da kommen nämlich sowohl die 1024 als auch die 1000 vor:
1 normales MB = 1 MiB = 1048576 Bytes
1 Disketten-MB = 1024000 Bytes (1,44 MB = 1440 kB = 1474560 Bytes)
1 Festplattenhersteller-MB = 1000000 Bytes
-
Aber wie bekommt ihr ein ganzes OS mit Teibern etc und GRUB drauf? Mehrere Disketten? Oder Festplatten?
-
Noch eine letzte Frage:
Ich habe mal angefangen, eine simple stdio-Libary zu programmieren. Aber jetzt gibt er mir folgenden Fehler:
video.h:5:19: error: expected ‘)’ before ‘output’
#ifndef VIDEO_H
#define VIDEO_H
void printf(char hw[]);
void putc(uint8_t output);
void refresh();
int getpointer();
void clearscreen();
#endif
void putc(uint8_t output)
{
pointerx = x;
pointery = y;
getpointer();
if (outputput != "\n" && output != "\0") {
// Zeichen i in den Videospeicher kopieren
buffer[pointer] = output[i];
// 0x07 = Hellgrau auf Schwarz
buffer[pointer + 1] = 0x07;
pointerx++;
} else if (output = "\n") {
pointerx = 0;
pointery++;
}
if (pointerx = 80) { pointerx = 0; pointery++; }
}
(Getpointer() holt sich die Addresse, an die der Text hinsoll)
-
Noch eine letzte Frage:
Ich habe mal angefangen, eine simple stdio-Libary zu programmieren. Aber jetzt gibt er mir folgenden Fehler:
video.h:5:19: error: expected ‘)’ before ‘output’
Solche Fehlermeldungen am besten erstmal wörtlich nehmen, und gucken was er da gemeint haben könnte. Er hat vor "output" etwas gefunden, das ihm nicht gefällt. Und was steht vor output in Zeile 5? "uint8_t" -> Du musst also in video.h noch den Header einbinden, der diesen Typ definiert. Das sollte stdint.h sein.
Du schreibst in der Funktion außerdem "\n" und "\0". Das wird so nicht funktionieren, weil das Zeichenketten sind. Du willst aber einzelne Zeichen vergleichen, und es muss deswegen '\n' und '\0' mit einzelnen Anführungszeichen lauten. Außerdem hast du einmal output = "\n" gehschrieben. Das ist eine Zuweisung und muss richtig output == '\n' lauten. Vergleiche gehen mit doppelten Gleichheitszeichen. Genau das selbe bei pointerx = 80.
Über den Rest klärt dich hoffentlich dein Compiler auf ;)
-
Uups, ich glaube, ich muss mir doch noch mal eine C-Referenz durchlesen...
P.S.: Ich bin VB .NET Veteran, das mit dem doppelten Gleichheitszeichen wird mir noch öfters passieren!
-
Aber wie bekommt ihr ein ganzes OS mit Teibern etc und GRUB drauf? Mehrere Disketten? Oder Festplatten?
Festplatten oder CDs. Wobei eine Diskette auch ganz schön lang reicht, solange man keine großartigen Daten (z.B. Bilder) drauf hat, sondern nur reinen Code.
P.S.: Ich bin VB .NET Veteran, das mit dem doppelten Gleichheitszeichen wird mir noch öfters passieren!
Lass dir vom Compiler auf die Finger hauen, wenn du Blödsinn machst: gcc -Wall -Wextra -Werror ;)
-
An Flags soll es gcc nicht mangeln:
-m32 -Wall -Wextra -Werror -nostdlib -nostdinc -nostartfiles -nodefaultlibs -ffreestanding -fno-stack-protector -c
-
Sorry, aber ich muss euch nochmal mit Code bombardieren... :-D
Diesmal mit Pastebin: http://pastebin.com/QLRSz78H (http://pastebin.com/QLRSz78H)
Das Problem: "nochma" steht nach den Punkten, nicht unter Halihalo. Bei weiteren Tests zeigt sich, dass mein Code nur die ersten beiden Seiten anfassen will.
-
Die Variable pointer sollte vom Typ unsigned short oder unsigned int sein. In unsigned char passen nur Werte bis 255.
-
ld überrascht einen immer wieder: :-o
/usr/bin/nasm -f elf32 -o a.elf boot.asm
cc -m32 -Wall -Wextra -Werror -nostdlib -nostdinc -nostartfiles -nodefaultlibs -ffreestanding -fno-stack-protector -c -o b.out kernel.c
cc -m32 -Wall -Wextra -Werror -nostdlib -nostdinc -nostartfiles -nodefaultlibs -ffreestanding -fno-stack-protector -c -o c.out video.c
/usr/bin/ld -T kernel.ld -melf_i386 -o kernel.elf a.elf b.out c.out
*** buffer overflow detected ***: /usr/bin/ld terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x40)[0xb739a070]
/lib/libc.so.6(+0xe8e27)[0xb7397e27]
/lib/libc.so.6(+0xe8445)[0xb7397445]
/lib/libc.so.6(_IO_default_xsputn+0x91)[0xb731ac31]
/lib/libc.so.6(_IO_vfprintf+0xec3)[0xb72ee103]
/lib/libc.so.6(__vsprintf_chk+0xcc)[0xb739751c]
/lib/libc.so.6(__sprintf_chk+0x2f)[0xb739742f]
/usr/bin/ld[0x80503d0]
/usr/bin/ld[0x8051392]
/usr/bin/ld[0x804dbf3]
/usr/bin/ld[0x80538c3]
/usr/bin/ld[0x8062604]
/lib/libc.so.6(__libc_start_main+0xfe)[0xb72c5c2e]
/usr/bin/ld[0x804d361]
======= Memory map: ========
08048000-0836b000 r-xp 00000000 08:16 9963519 /usr/bin/ld.bfd
0836b000-0836c000 r--p 00322000 08:16 9963519 /usr/bin/ld.bfd
0836c000-0836f000 rw-p 00323000 08:16 9963519 /usr/bin/ld.bfd
0836f000-08392000 rw-p 00000000 00:00 0 [heap]
b7256000-b7272000 r-xp 00000000 08:11 394400 /lib/libgcc_s.so.1
b7272000-b7273000 r--p 0001b000 08:11 394400 /lib/libgcc_s.so.1
b7273000-b7274000 rw-p 0001c000 08:11 394400 /lib/libgcc_s.so.1
b7296000-b7298000 rw-p 00000000 00:00 0
b7298000-b72ad000 r-xp 00000000 08:11 394207 /lib/libz.so.1.2.5
b72ad000-b72ae000 r--p 00014000 08:11 394207 /lib/libz.so.1.2.5
b72ae000-b72af000 rw-p 00015000 08:11 394207 /lib/libz.so.1.2.5
b72af000-b7415000 r-xp 00000000 08:11 394653 /lib/libc-2.11.3.so
b7415000-b7416000 ---p 00166000 08:11 394653 /lib/libc-2.11.3.so
b7416000-b7418000 r--p 00166000 08:11 394653 /lib/libc-2.11.3.so
b7418000-b7419000 rw-p 00168000 08:11 394653 /lib/libc-2.11.3.so
b7419000-b741c000 rw-p 00000000 00:00 0
b741c000-b741f000 r-xp 00000000 08:11 394661 /lib/libdl-2.11.3.so
b741f000-b7420000 r--p 00002000 08:11 394661 /lib/libdl-2.11.3.so
b7420000-b7421000 rw-p 00003000 08:11 394661 /lib/libdl-2.11.3.so
b7421000-b767d000 r-xp 00000000 08:16 11409880 /usr/lib/libbfd-2.21.so
b767d000-b767e000 ---p 0025c000 08:16 11409880 /usr/lib/libbfd-2.21.so
b767e000-b76b4000 r--p 0025c000 08:16 11409880 /usr/lib/libbfd-2.21.so
b76b4000-b76bb000 rw-p 00292000 08:16 11409880 /usr/lib/libbfd-2.21.so
b76bb000-b76c0000 rw-p 00000000 00:00 0
b76e1000-b76e3000 rw-p 00000000 00:00 0
b76e3000-b7702000 r-xp 00000000 08:11 397828 /lib/ld-2.11.3.so
b7702000-b7703000 r--p 0001e000 08:11 397828 /lib/ld-2.11.3.so
b7703000-b7704000 rw-p 0001f000 08:11 397828 /lib/ld-2.11.3.so
bf956000-bf977000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
make: *** [prog] Abgebrochen
Muss gleich mal gucken, was ich so verändert habe. Vor 5 Minuten war das noch nich so...
-
Glückwunsch, du hast einen Bug in ld gefunden. ;)
-
Hmm. Mich interessiert eher, wie ich diesen Bug wieder loswerde.
-
Hallo,
Hmm. Mich interessiert eher, wie ich diesen Bug wieder loswerde.
Wenn es wirklich ein Bug in ld ist dann gibt es da IMHO 2 Möglichkeiten:
1.: Du ziehst Dir den Source und fixt das Problem selber
2.: Du meldest Dich auf der binutils-Mailinglist an und berichtest von Deinem Problem
Ich persönlich würde Variante 2 bevorzugen auch wenn das gewisse Englischkenntnisse voraussetzt. Die Wahrscheinlichkeit das Dir dort zügig geholfen werden kann ist recht hoch. Desto leichter der Fehler reproduzierbar ist (genau das solltest Du versuchen sicherzustellen, z.B. indem Du das auch auf einer anderen Distribution testest) desto schneller kann Dir geholfen werden.
Grüße
Erik
-
Warum linkt ld die libc des Systems dazu? das sollte meines Wissens nach eigentlich nicht sein beim OS-Dev oder?
PNoob
-
Hallo,
Warum linkt ld die libc des Systems dazu? das sollte meines Wissens nach eigentlich nicht sein beim OS-Dev oder?
Die Memory-Map von gestern Abend ist IMHO von ld selber und das wird wohl schon die libc des Host-Systems benutzen müssen oder?
Grüße
Erik
-
Ich hab mal ein bisschen experimentiert, und wenn ich meine Linkerfile weglasse, sagt er nichts.
-
@erik: ich war wohl noch nicht ganz wach. Du hast recht, das ist von ld serlber und hat mit dem zu linkendem kram nichts zu tun
@tiger717: Poste dein Linkerscript doch mal
PNoob
-
Wenn ld abstürzt, ist das immer ein ld-Bug, egal wie das Linkerskript aussieht. Ein Fehler im Linkerskript könnte natürlich noch dazukommen.
Bugs in der Toolchain meldet man am besten, indem man erstmal einen minimalen Testcase baut (d.h. so lange Code rausnehmen, wie ld immer noch abstürzt) und das dann im Bugtracker von deiner Distribution eintragen (nicht auf der binutils-Mailingliste, weil deine Distribution ziemlich sicher noch dran rumgepatcht hat) und alle Dateien, die man für den minimalen Testcase noch braucht anzuhängen.
-
Linkerfile ist ganz normal, anders sind nur:
OUTPUT_FORMAT(elf32-i386)
OUTPUT_ARCH(i386:i386)
und *(multiboot)
(sorry wenn ich mich vertippt hab, bin gerade in Windows und kann nicht nachsehen)
-
Hallo,
indem man erstmal einen minimalen Testcase baut
Richtig, hatte ich heute Früh vergessen zu erwähnen.
und das dann im Bugtracker von deiner Distribution eintragen (nicht auf der binutils-Mailingliste, weil deine Distribution ziemlich sicher noch dran rumgepatcht hat)
Sicher? Ich persönlich würde es einfach mit einer anderen Distribution testen und wenn das Problem da identisch besteht dann doch lieber direkt zur Quelle, aber das ist nur meine persönliche Meinung (ich hab mal ne Weile lang die binutils-Mailingliste verfolgt und da wurde schon ab und an mal ein Bug berichtet und oft auch gefixt). Wenn das Problem distributionsspezifisch ist (scheint) dann natürlich doch an die Distribution.
Aber wenn taljeth empfiehlt das eher gleich an den distributionsspezifischen Bugtracker zu schicken dann sollte man das sicher befolgen, der taljeth ist ja schließlich vom Fach. Englisch wird aber bestimmt auch dort Pflicht sein.
Grüße
Erik
-
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).
-
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
-
Zumal Ubuntu oft an irgendwelchen Sourcen rumpatcht, bevor es dann im Repository landet. :roll:
-
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
-
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...
-
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
-
hab openSUSE 11.4, aber gcc und binutils selber kompilieren? Das überlass ich lieber Richard Stallmann ^^
-
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. ;)
-
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
-
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...
-
Das heißt du bist gar nicht 717 Jahre alt? Mensch, ich wusste doch, dass was faul ist.
-
Nein, Riesen-Schildkröten in der OS-Dev Branche wird es nie geben!
-
Nein, Riesen-Schildkröten in der OS-Dev Branche wird es nie geben!
woher willst du das Wissen? vielleicht bin ich ja eine ;)
PNoob
-
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? :-D
-
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://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 (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.
-
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.
-
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:
/* 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.