Autor Thema: Anmerkungen zu OS-Dev für Einsteiger - Teil 4  (Gelesen 7002 mal)

arax

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« am: 29. March 2010, 10:56 »
Neben meinem GRUB Problem hatte ich danach noch zwei weitere Probleme beim ersten Teil von Teil 4:
Der Kernel verlangt offenbar etwa 150 MB, sonst gibt GRUB den Error 28. Woran liegt das?
Dazu lief das Image bei mir nicht mit Qemu sondern nur mit bochs (Qemu: "Hello world" wird nicht ausgegeben).

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 29. March 2010, 11:16 »
Sieht deine Kernelbinary denn vernünftig aus? Also Dateigröße, Ausgabe von readelf -lS und ähnliches.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

arax

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 29. March 2010, 17:33 »
Dateigröße: 10253 byte

readelf -lS kernel:
Zitat
There are 18 section headers, starting at offset 0x23a4:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00100000 001000 00007c 00  AX  0   0  4
  [ 2] .rel.plt          REL             080480b4 0020b4 000000 08   A  0   3  4
  [ 3] .plt              PROGBITS        080480b4 0020b4 000000 00  AX  0   0  4
  [ 4] .got.plt          PROGBITS        00101000 002000 000000 00  WA  0   0  4
  [ 5] .bss              NOBITS          00101000 002000 002000 00  WA  0   0  4
  [ 6] .comment          PROGBITS        00000000 0020b4 000023 01  MS  0   0  1
  [ 7] .debug_aranges    PROGBITS        00000000 0020d7 000020 00      0   0  1
  [ 8] .debug_pubnames   PROGBITS        00000000 0020f7 00001b 00      0   0  1
  [ 9] .debug_info       PROGBITS        00000000 002112 000093 00      0   0  1
  [10] .debug_abbrev     PROGBITS        00000000 0021a5 00008a 00      0   0  1
  [11] .debug_line       PROGBITS        00000000 00222f 00003f 00      0   0  1
  [12] .debug_frame      PROGBITS        00000000 002270 00002c 00      0   0  4
  [13] .debug_str        PROGBITS        00000000 00229c 000032 01  MS  0   0  1
  [14] .debug_loc        PROGBITS        00000000 0022ce 00002c 00      0   0  1
  [15] .shstrtab         STRTAB          00000000 0022fa 0000a9 00      0   0  1
  [16] .symtab           SYMTAB          00000000 002674 000160 10     17  17  4
  [17] .strtab           STRTAB          00000000 0027d4 000039 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x100070
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00100000 0x00100000 0x0007c 0x0007c R E 0x1000
  LOAD           0x002000 0x00101000 0x00101000 0x00000 0x02000 RW  0x1000
  LOAD           0x0020b4 0x080480b4 0x080480b4 0x00000 0x00000 R E 0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .bss
   02     
   03     

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #3 am: 29. March 2010, 17:40 »
hm, die Program Header sieht komisch aus, speziell der Teil
Zitat
  LOAD           0x0020b4 0x080480b4 0x080480b4 0x00000 0x00000 R E 0x1000
Du könntest mal ein
Zitat
/DISCARD/ : { *(.comment) }
am Ende des Linkerskripts (aber vor der schließenden Klammer '}') versuchen.
« Letzte Änderung: 29. March 2010, 18:33 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

arax

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 30. March 2010, 11:42 »
Das Linkerscript hatte ich bei der Imageerstellung noch gar nicht verwendet, also war ich nur bis "Multiboot-Header in einer eigenen Sektion".
Ich bin jetzt dem Abschnitt gefolgt, das verändert aber nichts an den Problemen.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 30. March 2010, 12:31 »
.comment sieht auch harmlos aus, wenn ich das richtig lese:

  [ 2] .rel.plt          REL             080480b4 0020b4 000000 08   A  0   3  4
  [ 3] .plt              PROGBITS        080480b4 0020b4 000000 00  AX  0   0  4
Die hier haben ein Offset, das eher nicht so richtig passt. Ich weiß jetzt allerdings nicht, unter welchen Umständen .plt erzeugt wird. Musst du halt schauen, wie du die am elegantesten loswirst.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #6 am: 30. March 2010, 12:37 »
Bei -fpic, -fPIC, -fpie oder -fPIE d.h. bei position-independant-code. Du hast den Code aber schon wie im Tutorial angegeben kompiliert, oder? Und zum linken muss man dieses bzw. ein eigenes Linkerscript verwenden.

Zitat
Die hier haben ein Offset, das eher nicht so richtig passt.
Das ist eigentlich die Adresse und nicht das Offset, oder? Macht es aber nicht besser.
« Letzte Änderung: 30. March 2010, 12:40 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

arax

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 30. March 2010, 13:58 »
@taljeth
Zitat
"Musst du halt schauen, wie du die am elegantesten loswirst."
Ich habe kein praktisches Problem mehr, es funktioniert ja bei bochs mit mehr RAM. Mir geht es darum darauf hinzuweisen, dass es bei mir bei Befolgung der Anweisungen im Tutorial nicht funktioniert.

@bluecode
Ich habe den Code gemäß den Anweisungen kompiliert und der Kernel funktioniert auch.
Zitat
zum linken muss man dieses bzw. ein eigenes Linkerscript verwenden.
Dem Linker wird das "-Ttext=0x100000" ja direkt übergeben, also ist kein Linkerscript erforderlich (denke ich, wird auch nichts im Tutorial gesagt). Erst später folgt:
Zitat
Außerdem erstellen wir ein Linkerskript, die Datei kernel.ld

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #8 am: 30. March 2010, 14:29 »
Du könntest mal das git des Tutorials auschecken über
git clone git://git.tyndur.org/tutorial.git tutorialdann dort das Makefile aufrufen und anschließend "kernel" objdumpen.
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

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 30. March 2010, 14:32 »
Ich habe kein praktisches Problem mehr, es funktioniert ja bei bochs mit mehr RAM. Mir geht es darum darauf hinzuweisen, dass es bei mir bei Befolgung der Anweisungen im Tutorial nicht funktioniert.
Schon klar, aber solange es keine Lösung gibt, kann man das Tutorial auch nicht ausbessern.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

arax

  • Beiträge: 27
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 31. March 2010, 15:34 »
@taljeth
Funktioniert es den bei dir, wenn du nur die erste Codeversion kompilierst?

@bluecode

Wenn ich den ausgecheckten Code kompiliere funktioniert es auch mit weniger RAM (hab' nur mit bochs getested).

Ich weiß nicht ob du den objdump noch brauchst und mit welchen Parametern:
Zitat
objdump -x kernel

kernel:     file format elf32-i386
kernel
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x001005d4

Program Header:
    LOAD off    0x00001000 vaddr 0x00100000 paddr 0x00100000 align 2**12
         filesz 0x0000112d memsz 0x0000112d flags r-x
    LOAD off    0x00003000 vaddr 0x00102000 paddr 0x00102000 align 2**12
         filesz 0x00001075 memsz 0x00024860 flags rw-
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rwx

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000112d  00100000  00100000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         000000a0  00102000  00102000  00003000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rodata       00000075  00103000  00103000  00004000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .bss          00022860  00104000  00104000  00004075  2**5
                  ALLOC
  4 .debug_abbrev 0000050f  00000000  00000000  00004075  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   00000ca4  00000000  00000000  00004584  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_line   0000034a  00000000  00000000  00005228  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_loc    0000044c  00000000  00000000  00005572  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_pubnames 00000103  00000000  00000000  000059be  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_aranges 000000a0  00000000  00000000  00005ac1  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    0000036e  00000000  00000000  00005b61  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .comment      00000023  00000000  00000000  00005ecf  2**0
                  CONTENTS, READONLY
 12 .debug_frame  000002ec  00000000  00000000  00005ef4  2**2
                  CONTENTS, READONLY, DEBUGGING
SYMBOL TABLE:
00100000 l    d  .text   00000000 .text
00102000 l    d  .data   00000000 .data
00103000 l    d  .rodata   00000000 .rodata
00104000 l    d  .bss   00000000 .bss
00000000 l    d  .debug_abbrev   00000000 .debug_abbrev
00000000 l    d  .debug_info   00000000 .debug_info
00000000 l    d  .debug_line   00000000 .debug_line
00000000 l    d  .debug_loc   00000000 .debug_loc
00000000 l    d  .debug_pubnames   00000000 .debug_pubnames
00000000 l    d  .debug_aranges   00000000 .debug_aranges
00000000 l    d  .debug_str   00000000 .debug_str
00000000 l    d  .comment   00000000 .comment
00000000 l    d  .debug_frame   00000000 .debug_frame
00106014 l       .bss   00000000 kernel_stack
00100082 l       .text   00000000 intr_common_handler
00000000 l    df *ABS*   00000000 console.c
00104000 l     O .bss   00000004 x
00104004 l     O .bss   00000004 y
00102000 l     O .data   00000004 video
00104008 l     O .bss   00000004 kprintf_res
001000ac l     F .text   0000011d kputc
001001c9 l     F .text   00000029 kputs
001001f2 l     F .text   0000006a kputn
00000000 l    df *ABS*   00000000 init.c
00000000 l    df *ABS*   00000000 tasks.c
0010400c l     O .bss   00000004 first_task
00104010 l     O .bss   00000004 current_task
00100408 l     F .text   00000014 task_a
0010041c l     F .text   00000014 task_b
00100430 l     F .text   00000014 task_c
00100444 l     F .text   00000014 task_d
00000000 l    df *ABS*   00000000 intr.c
00106020 l     O .bss   00000030 gdt
00102020 l     O .data   00000080 tss
00106060 l     O .bss   00000800 idt
001005e4 l     F .text   000001fb gdt_set_entry
001008e0 l       .text   00000000 .1
001008ea l     F .text   0000013a idt_set_entry
00100a24 l     F .text   0000001e outb
00100a42 l     F .text   000000d0 init_pic
00000000 l    df *ABS*   00000000 mm_phys.c
00100f14 l     F .text   00000030 memset
00106860 l     O .bss   00020000 bitmap
001010a1 l     F .text   00000047 pmm_mark_used
0010025c g     F .text   00000041 clrscr
00100b12 g     F .text   0000034d init_intr
00100540 g     F .text   00000038 init_multitasking
00100070 g       .text   00000000 intr_stub_32
00100012 g       .text   00000000 intr_stub_1
00100ffa g     F .text   000000a7 pmm_alloc
00100e5f g     F .text   000000b3 handle_interrupt
0010004a g       .text   00000000 intr_stub_11
0010007c g       .text   00000000 intr_stub_48
00100578 g     F .text   0000005a schedule
00100060 g       .text   00000000 intr_stub_16
00100458 g     F .text   000000e8 init_task
001010e8 g     F .text   00000045 pmm_free
0010000c g       .text   00000000 intr_stub_0
00100018 g       .text   00000000 intr_stub_2
00100024 g       .text   00000000 intr_stub_4
001005d4 g       .text   00000000 _start
00100076 g       .text   00000000 intr_stub_33
00127000 g       *ABS*   00000000 kernel_end
001007df g     F .text   0000010b init_gdt
001003cc g     F .text   0000003a init
00100036 g       .text   00000000 intr_stub_7
00100056 g       .text   00000000 intr_stub_14
0010006a g       .text   00000000 intr_stub_18
0010005a g       .text   00000000 intr_stub_15
00100030 g       .text   00000000 intr_stub_6
00100f44 g     F .text   000000b6 pmm_init
0010003c g       .text   00000000 intr_stub_8
0010029d g     F .text   0000012e kprintf
00100040 g       .text   00000000 intr_stub_9
0010001e g       .text   00000000 intr_stub_3
0010002a g       .text   00000000 intr_stub_5
0010004e g       .text   00000000 intr_stub_12
00100000 g       *ABS*   00000000 kernel_start
00100066 g       .text   00000000 intr_stub_17
00100052 g       .text   00000000 intr_stub_13
00100046 g       .text   00000000 intr_stub_10


bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #11 am: 31. March 2010, 15:42 »
Das Problem lässt sich durch das Linkerscript so wie ich das sehe kaschieren, dann landet die .plt Sektion nicht an irgendwelchen wirren Adressen, das behebt dein Problem.

Ansonsten konnte ich auch mit dem Code im git das Problem, das überhaupt eine .plt Sektion erstellt wird, reproduzieren. Das taucht aber nur mit den ersten beiden Commits auf, ab dem dritten funktioniert es problemlos. Ich habe aber keinen blassen Schimmer was an dem 3ten Commit ursächlich für das Verschwinden der .plt-Sektion ist, aber ich könnte mir vorstellen, dass es ein Bug in den (Debian/Ubuntu?) binutils ist.
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

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 31. March 2010, 16:32 »
@taljeth
Funktioniert es den bei dir, wenn du nur die erste Codeversion kompilierst?
Ja, sowohl unter Fedora als auch openSUSE.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

 

Einloggen