Thema: C-Kernel ohne Multiboot

[kevin]

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

[tiger717]

Aber wie bekommt ihr ein ganzes OS mit Teibern etc und GRUB drauf? Mehrere Disketten? Oder Festplatten?

[tiger717]

Noch eine letzte Frage:

Ich habe mal angefangen, eine simple stdio-Libary zu programmieren. Aber jetzt gibt er mir folgenden Fehler:

Code: [Auswählen]

video.h:5:19: error: expected ‘)’ before ‘output’

Code: [Auswählen]

#ifndef VIDEO_H
#define VIDEO_H

void printf(char hw[]);
void putc(uint8_t output);
void refresh();
int getpointer();
void clearscreen();

#endif

Code: [Auswählen]

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)

[Jidder]

Noch eine letzte Frage:

Ich habe mal angefangen, eine simple stdio-Libary zu programmieren. Aber jetzt gibt er mir folgenden Fehler:

Code: [Auswählen]

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

[tiger717]

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!

[kevin]

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

[tiger717]

An Flags soll es gcc nicht mangeln:

Code: [Auswählen]

-m32 -Wall -Wextra -Werror -nostdlib -nostdinc -nostartfiles -nodefaultlibs -ffreestanding -fno-stack-protector -c

[tiger717]

Sorry, aber ich muss euch nochmal mit Code bombardieren... 

Diesmal mit Pastebin: 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.

[Jidder]

Die Variable pointer sollte vom Typ unsigned short oder unsigned int sein. In unsigned char passen nur Werte bis 255.

[tiger717]

ld überrascht einen immer wieder: 

Code: [Auswählen]

/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...

[kevin]

Glückwunsch, du hast einen Bug in ld gefunden.

[tiger717]

Hmm. Mich interessiert eher, wie ich diesen Bug wieder loswerde.

[erik.vikinger]

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

[PNoob]

Warum linkt ld die libc des Systems dazu? das sollte meines Wissens nach eigentlich nicht sein beim OS-Dev oder?

PNoob

[erik.vikinger]

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

[tiger717]

Ich hab mal ein bisschen experimentiert, und wenn ich meine Linkerfile weglasse, sagt er nichts.

[PNoob]

@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

[kevin]

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.

[tiger717]

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)

[erik.vikinger]

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