Autor Thema: Merkwürdiger c Fehler  (Gelesen 5773 mal)

Hauke

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« am: 04. October 2008, 14:02 »
Ich wollte den c Kernel weiter versuchen, das laden und linken funktioniert auch, aber er zeigt zwar etwas an, aber anderer Zeichen, mit einer anderen Länge.  Wenn ich jetzt statt der Schleife  n mal den Inhalt der Schleife stehen habe funktioniert es. Somit kann dass ja irgend wie kein Falscher Zeiger sein, sondern das weis ich ja nicht. Ich hoffe jemand hat eine Idee woran das liegen könnte.
So erstelle ich das (nur ein Teile)
gcc -ffreestanding -c -Os -Wall -o ckernel.obj kernel.c

Hier ist der Code:
int main()
{
int i=0;
char *Text = "Das ist ein Test"; 
char *Video = (char*)0xB8000; 

while(*Text) 

*Video++ = *Text;
*Video++ = 7;
Text++;
i++;
}
return i; //nur zur Überprüfung
}

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #1 am: 04. October 2008, 15:05 »
Versuch es mal ohne Optimierungen (also -O0), denn wenn du die Schleife entfernst und den Code n-Mal hinschreibst, könnte der Compiler wahrscheinlich leichter auf die Idee kommen den String komplett wegzuoptimieren und gleich die einzelnen Zeichen an die entsprechende Stelle schreibe. Disassemblieren des Codes könnte auch helfen.

Ich habs während ich den Beitrag geschrieben habe ausprobiert und es ist exakt das was bei mir passiert.

edit: Explizit gesagt: Mit -O0 sollte der Code ohne Schleife auch schiefgehen und du kannst eben nicht ausschließen, dass der Zeiger falsch ist. Wahrscheinlich verursacht dadurch, dass die Adress, die du beim Linken angibst nicht mit dem Ladevorgang deines Bootloaders verträglich ist oder dadurch das du Segmentierung mit Segmentbasen != 0 benutzt.
« Letzte Änderung: 04. October 2008, 15:10 von bluecode »
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Hauke

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 05. October 2008, 13:21 »
OK er Optimiert das dann tatsächlich weg.
Und weiter liegt es an der Adresse, die gelinkt worden ist (der teil, wo der ProtectMode eingeschaltet wird), was mich nur Wundert, da der Rest Funktionierte.
Eine Frage hab ich noch wie kann ich bei Bochs einen Break Point auf z.B. Adresse (Im ProtectMode) 0x8:0x10000  so hab ich das schon ausprobiert :
vb 0x8:0x10000   oder b 0x10000.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #3 am: 05. October 2008, 15:34 »
Man gibt afaik bei bochs das Segmentregister garnicht bei den Breakpoints an. Ich glaube ich habe immer "lb <adresse>" genommen. Damit ist die Adresse dann vor dem Paging und nach Segmentierung gemeint.

Ich bin mir nicht sicher ob ich das andere richtig verstanden habe: War die Linkadresse jetzt falsch und hat das Ändern der Adresse das o.g. Problem behoben?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Hauke

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 05. October 2008, 16:15 »
Das mit dem Breakpoint funktioniert mit dem genannten. :-)

Mit dem anderren, da hab ich den Teil, der den ProtectMode Einschaltet, auf eine konstante länge gesetzt (mit times …) und diese länge, dann im Link Script aufaddiert.
jmp PMODE3

times 0x200-($-$$) db 0
PMODE3:

.text  0x10200 : {

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #5 am: 05. October 2008, 16:20 »
Ehm... letzeres würde ich mal als "dubios" bezeichnen. So wie es aussieht linkst du den Protected-Mode stub extra und hängst denn dann vorne an die restliche Kernelbinary ran, oder wie? Wäre sinnvoll wenn du mal sagst wie genau du deinen Kernel compilierst und linkst...
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Hauke

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 05. October 2008, 16:54 »
Also ich zeig einfach mal meine Batch Datei und den Link Script.

nasm -f bin -o boot_1.bin boot_1.asm
nasm -f bin -o h_os_1_1.bin h_os_1_1.asm
nasm -f aout -o kernel32.obj kernel32.asm

gcc -ffreestanding -c -Wall -o ckernel.obj kernel.c

ld -T link.txt -o c32kernel.bin

copy /y/b/v boot_1.bin + h_os_1_1.bin + c32kernel.bin d:\Programme\Bochs-2.3.5\h_os\h_os_1.img

cd ..
d:
cd d:\Programme\Bochs-2.3.5\h_os
..\bochsdbg.exe -q -f bochsrc.bxrc

OUTPUT_FORMAT("binary")
INPUT(kernel32.obj ckernel.obj)
ENTRY(start)
SECTIONS
{
  .text  0x10200 : {
    code = .; _code = .; __code = .;
    *(.text)
    . = ALIGN(1);
  }
  .data  : {
    data = .; _data = .; __data = .;
    *(.data)
    . = ALIGN(1);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(1);
  }
  end = .; _end = .; __end = .;
}

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #7 am: 05. October 2008, 17:07 »
Ja gut, dann sind die falschen Pointer natürlich kein Wunder. Du linkst ja nicht wirklich die Sachen zusammen, sondern hängst nur die Binärdaten aneinander... Ich würde dir empfehlen den Assembler und C-code zuerst zu Objektdateien (kA, aber -f aout für den ges. asmcode sollte tun und dann natürlich nicht bla.bin sondern bla.obj) zu assembleren und danach mit ld und dem Linkerscript mit 0x10000 zu linken.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Hauke

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 06. October 2008, 14:18 »
OK
ich denke, ich lasse das ersteinmal so, weil ich dann genau weis, dass der
c Kernel dort ist, womit der c Kernel leicht verschoben werden kann.
Außerdem soll doch der gcc mit gemischten 16 und 32 Bit Code nicht so zu recht kommen, soviel ich weis.

 

Einloggen