Lowlevel
Lowlevel => Das Wiki => Thema gestartet von: arax am 29. March 2010, 10:56
-
Neben meinem GRUB Problem (http://lowlevel.brainsware.org/forum/index.php?topic=2477.0) 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).
-
Sieht deine Kernelbinary denn vernünftig aus? Also Dateigröße, Ausgabe von readelf -lS und ähnliches.
-
Dateigröße: 10253 byte
readelf -lS kernel:
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
-
hm, die Program Header sieht komisch aus, speziell der Teil
LOAD 0x0020b4 0x080480b4 0x080480b4 0x00000 0x00000 R E 0x1000
Du könntest mal ein
/DISCARD/ : { *(.comment) }
am Ende des Linkerskripts (aber vor der schließenden Klammer '}') versuchen.
-
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.
-
.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.
-
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.
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.
-
@taljeth
"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.
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:
Außerdem erstellen wir ein Linkerskript, die Datei kernel.ld
-
Du könntest mal das git des Tutorials (http://git.tyndur.org/?p=tutorial.git;a=summary) auschecken über
git clone git://git.tyndur.org/tutorial.git tutorialdann dort das Makefile aufrufen und anschließend "kernel" objdumpen.
-
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.
-
@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:
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
-
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.
-
@taljeth
Funktioniert es den bei dir, wenn du nur die erste Codeversion kompilierst?
Ja, sowohl unter Fedora als auch openSUSE.