Nachrichten

61

Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel

« am: 18. December 2011, 16:09 »

Das ist in dem Ausschnitt auch vorhanden.
Direkt der erste Dump nach dem after RSM.
Oder verstehe ich dich falsch?

62

Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel

« am: 18. December 2011, 15:43 »

Hier mal der Log von QEmu:

Code: [Auswählen]

SMM: enter
EAX=00000001 EBX=07fe0cb0 ECX=00000000 EDX=00000cfc
ESI=000f27cd EDI=0003802d EBP=07fe0ad0 ESP=00006f3c
EIP=000f3766 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     000fcd80 00000037
IDT=     000fdb70 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=000f27a0 CCD=00000001 CCO=LOGICB 
EFER=0000000000000000
SMM: after RSM
EAX=00000001 EBX=07fe0cb0 ECX=00000000 EDX=00000cfc
ESI=000f27cd EDI=0003802d EBP=07fe0ad0 ESP=00006f3c
EIP=000f3766 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     000fcd80 00000037
IDT=     000fdb70 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS 
EFER=0000000000000000
check_exception old: 0xffffffff new 0x0
     0: v=00 e=0000 i=0 cpl=0 IP=0008:00000000001017ac pc=00000000001017ac SP=0010:00000000c0003a2c EAX=0000000000000001
EAX=00000001 EBX=00009500 ECX=00000007 EDX=00000000
ESI=00000000 EDI=00108000 EBP=c0003a58 ESP=c0003a2c
EIP=001017ac EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000000 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=ADDL   
EFER=0000000000000000
check_exception old: 0x0 new 0xd
     1: v=08 e=0000 i=0 cpl=0 IP=0008:00000000001017ac pc=00000000001017ac SP=0010:00000000c0003a2c EAX=0000000000000001
EAX=00000001 EBX=00009500 ECX=00000007 EDX=00000000
ESI=00000000 EDI=00108000 EBP=c0003a58 ESP=c0003a2c
EIP=001017ac EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000000 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=ADDL   
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
     2: v=0d e=8000 i=0 cpl=0 IP=0008:00000000c0000d65 pc=00000000c0000d65 SP=0010:00000000c0003a00 EAX=0000000000108000
EAX=00108000 EBX=00000000 ECX=c00039e8 EDX=00000007
ESI=c0003a58 EDI=00000000 EBP=00009500 ESP=c0003a00
EIP=c0000d65 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000000 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=LOGICL 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
     3: v=0e e=0000 i=0 cpl=0 IP=0008:00000000c0000d72 pc=00000000c0000d72 SP=0010:00000000c00039f0 CR2=0000000000000d60
EAX=00000010 EBX=00000007 ECX=c00039c0 EDX=c00039e8
ESI=00009500 EDI=c0003a58 EBP=00000000 ESP=c00039f0
EIP=c0000d72 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0000 00000000 00000000 00000000
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000d60 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000008 CCD=c00039f0 CCO=ADDL   
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
     4: v=0d e=3a58 i=0 cpl=0 IP=0008:00000000c0000d65 pc=00000000c0000d65 SP=0010:00000000c00039c8 EAX=00000000c0003a58
EAX=c0003a58 EBX=c00039e8 ECX=c00039b0 EDX=c00039c0
ESI=00000000 EDI=00009500 EBP=00000007 ESP=c00039c8
EIP=c0000d65 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000d60 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000008 CCD=00000000 CCO=LOGICL 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
     5: v=0d e=9500 i=0 cpl=0 IP=0008:00000000c0000d65 pc=00000000c0000d65 SP=0010:00000000c00039a0 EAX=0000000000009500
EAX=00009500 EBX=c00039c0 ECX=c0003988 EDX=c00039b0
ESI=00000007 EDI=00000000 EBP=c00039e8 ESP=c00039a0
EIP=c0000d65 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000d60 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000008 CCD=00000000 CCO=LOGICL 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
     6: v=0e e=0000 i=0 cpl=0 IP=0008:00000000c0000d72 pc=00000000c0000d72 SP=0010:00000000c0003990 CR2=0000000000000d60
EAX=00000010 EBX=c00039b0 ECX=c0003960 EDX=c0003988
ESI=c00039e8 EDI=00000007 EBP=c00039c0 ESP=c0003990
EIP=c0000d72 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0000 00000000 00000000 00000000
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000d60 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000008 CCD=c0003990 CCO=ADDL   
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
     7: v=0e e=0000 i=0 cpl=0 IP=0008:00000000c0000d65 pc=00000000c0000d65 SP=0010:00000000c0003968 CR2=0000000000000000
EAX=00000007 EBX=c0003988 ECX=c0003950 EDX=c0003960
ESI=c00039c0 EDI=c00039e8 EBP=c00039b0 ESP=c0003968
EIP=c0000d65 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000000 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000094 CCD=00000000 CCO=LOGICL 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
     8: v=0d e=39e8 i=0 cpl=0 IP=0008:00000000c0000d65 pc=00000000c0000d65 SP=0010:00000000c0003940 EAX=00000000c00039e8
EAX=c00039e8 EBX=c0003960 ECX=c0003928 EDX=c0003950
ESI=c00039b0 EDI=c00039c0 EBP=c0003988 ESP=c0003940
EIP=c0000d65 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     c0003000 00000027
IDT=     c0003028 000007ff
CR0=80000011 CR2=00000000 CR3=00080000 CR4=00000010
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000

Der Trace geht immer so weiter. Habe hier jetzt mal abgebrochen.

Werdet ihr daraus schauer als ich?

63

Lowlevel-Coding / Re: IDT mit einem Upper-Half-Kernel

« am: 18. December 2011, 13:21 »

Wenn ich mir mal den TLB in QEmu anschaue, passt das alles.
Da ist Paging richtig initialisiert.

64

Lowlevel-Coding / IDT mit einem Upper-Half-Kernel

« am: 18. December 2011, 11:14 »

Hallo zusammen,

ich habe einen Upper-Half-Kernel und versuche gerade die IDt zu initialisieren.
Ich habe haeufiger gelesen, dass in der IDTR die physischen Adresse der IDT stehen muss. Da hab ich nur das Problem, dass ich bei der Behandlung einer Exception einen PageFault bekomme, der auf die Position der IDT zeigt.
Wenn die IDT an einer virtuellen Adresse liegt, bekomme ich bei einer Exceptionen eine GPF.
Die Exception erzeuge ich mit 1 / 0. Dafuer ist auch ein Handler registiert, der aktiv ist und auf eine virtuelle Adresse zeigt.
Somit muesste die Exception behandelt werden. Kann das Problem auch an der GDT liegen?
Die wird ueber ihre physische Adresse identifiziert.

Die Handler-Adressen in der IDT muessen die virtuellen Adressen enthalten, oder?

Gruss,
Sven

EDIT:
Bochs gibt folgende Fehlermeldung:
bx_dbg_read_linear: physical memory read error (phy=0x00000000c0000dea, lin=0xc0000dea)

65

Lowlevel-Coding / Call auf 0x500 erzeugt GPF

« am: 23. October 2011, 14:45 »

Hi zusammen,

ich habe mir gerade mal Code geschrieben, der zurück in den RM springt, dort BIOS-Interrupts verwenden soll und dann zurück in den PM springen muss. Der Code wird ordentlich gebaut und als Flat-Binary gelinkt. Der Linker nutzt 0x500 als Basisadresse.
Wenn ich nun den Code mit .incbin in meinen Kernel einbinde und dann auf 0x500 kopiere, sollte ja alles soweit funktionieren.
Leider gibt es beim Call auf 0x500 einen GPF und der Error-Code ist 0x5b4.

Woran kann das liegen?
Kann es sein, dass was mit der GDT von GRUB nicht passt oder so?

Gruß,
rizor

66

Lowlevel-Coding / Re: switch setzt EIP auf 0x0

« am: 27. September 2011, 23:29 »

Ja, der Kernel wird gegen 3GB gelinkt, allerdings nicht dieser Code.
Der wird weiterhin gegen die 1MB-Grenze gelinkt.
Innerhalb dieser Funktion wird ja keine andere Funktion aufgerufen. Also duerfte das ja keine Probleme machen, oder?
Kann es sein, dass der Compiler irgendwie was falsch interpretiert und somit der Meinung ist, dass die Werte bei 3GB liegen?

67

Lowlevel-Coding / switch setzt EIP auf 0x0

« am: 27. September 2011, 22:53 »

Nabend zusammen,

ich bin gerade dabei die ACPI-Tabellen auszulesen und habe mir eine Switch-Anweisung geschrieben, damit ich die verschiedenen APIC-Strukturen aus der MADT auslesen kann.
Diese Anweisung setzt den EIP auf 0x0.

Hier der Code:

Code: [Auswählen]

switch (apic->type) {
case MADT_LAPIC:
lapic = (struct lapic*)apic;
offset = sizeof(struct lapic);

if(hit_if(!lapic->flags))
cpu_count++;
break;
case MADT_IO_APIC:
offset = sizeof(struct ioapic);
break;
case MADT_INT_SRC_OVERRIDE:
offset = sizeof(struct int_src_override);
break;
case MADT_NMI:
offset = sizeof(struct nmi);
break;
case MADT_LAPIC_NMI:
offset = sizeof(struct lapic_nmi);
break;
case MADT_LAPIC_ADDR_OVERRIDE:
offset = sizeof(struct lapic_address_override);
break;
case MADT_IO_SAPIC:
offset = sizeof(struct io_sapic);
break;
case MADT_LOCAL_SAPIC:
offset = sizeof(struct local_sapic);
break;
case MADT_PLATFORM_INT_SRC:
offset = sizeof(struct platform_int_src);
break;
default:
offset = sizeof(struct apic_header);
break;
}

Wenn ich diesen Code mit if-else-Anweisung verwende, funktioniert alles einwandfrei.
Woran liegt das?

Hier mal der Assembler-Code:

Code: [Auswählen]

while (i < madt->header.length) {
  100016: e9 c5 00 00 00        jmp    1000e0 <acpi_count_cpus+0xe0>
apic = (struct apic_header*)addr;
  10001b: 8b 44 24 1c          mov    0x1c(%esp),%eax
  10001f: 89 44 24 0c          mov    %eax,0xc(%esp)

switch (apic->type) {
  100023: 8b 44 24 0c          mov    0xc(%esp),%eax
  100027: 0f b6 00              movzbl (%eax),%eax
  10002a: 0f be c0              movsbl %al,%eax
  10002d: 83 f8 08              cmp    $0x8,%eax
  100030: 0f 87 8b 00 00 00    ja     1000c1 <acpi_count_cpus+0xc1>
  100036: 8b 04 85 00 10 00 c0 mov    -0x3ffff000(,%eax,4),%eax
  10003d: ff e0                jmp    *%eax
case MADT_LAPIC:
lapic = (struct lapic*)apic;
  10003f: 8b 44 24 0c          mov    0xc(%esp),%eax
  100043: 89 44 24 10          mov    %eax,0x10(%esp)
offset = sizeof(struct lapic);
  100047: c7 44 24 14 08 00 00 movl   $0x8,0x14(%esp)
  10004e: 00

if(hit_if(!lapic->flags))
  10004f: 8b 44 24 10          mov    0x10(%esp),%eax
  100053: 8b 40 04              mov    0x4(%eax),%eax
  100056: 85 c0                test   %eax,%eax
  100058: 0f 94 c0              sete   %al
  10005b: 0f b6 c0              movzbl %al,%eax
  10005e: 85 c0                test   %eax,%eax
  100060: 74 69                je     1000cb <acpi_count_cpus+0xcb>
cpu_count++;
  100062: a1 f0 05 10 00        mov    0x1005f0,%eax
  100067: 83 c0 01              add    $0x1,%eax
  10006a: a3 f0 05 10 00        mov    %eax,0x1005f0
break;
  10006f: eb 5b                jmp    1000cc <acpi_count_cpus+0xcc>

Kann mir nur vorstellen, dass jmp *%eax den Fehler verursacht.

Gruss,
rizor

68

Softwareentwicklung / Re: Makefile Erweiterung von Variablen

« am: 19. September 2011, 21:03 »

Danke. Jetzt funktioniert alles.

69

Softwareentwicklung / Re: Makefile Erweiterung von Variablen

« am: 19. September 2011, 20:20 »

Danke fuer die Tipps. Das hat soweit funktioniert.
Jetzt habe ich nur leider ein anderes Problem.
Ich habe in den If-Zweig das gesamte Build-Skript gebaut.
Das Skript sieht jetzt wie folgt aus:

Code: [Auswählen]

ifneq ($(shell find . -type f -name '.config'),)

ifeq ($(shell grep ARCH .config), CONFIG_ARCH_X86_32)
CFLAGS+="-m32 -march=i686"
LDFLAGS+="-Tarch/x86/linker.ld -melf_i386 -o"
KERNEL+="arch/x86"
endif

CFLAGS+=$(shell for i in `cat .config`; do echo " -D$$i"; done)
CFLAGS+="-c -o"

SRC_C:=$(shell find $(KERNEL) -type f -name '*.c')
SRC_ASM:=$(shell find $(KERNEL) -type f -name '*.S')
SRC:="$(SRC_C) $(SRC_ASM)"
OBJ:="$(patsubst %.c,%.o,$(SRC_C)) $(patsubst %.S,%.o,$(SRC_ASM))"
BUILD:=nerdy-kernel

.PHONY: clean

-include $(OBJ:.o=.d)

build: $(BUILD)

$(BUILD): $(OBJ)
@echo " LD " $@
$(LD) $(LDFLAGS) $@ $^

%.o: %.c
@echo " CC " $@
$(GCC) $(CFLAGS) $@ $<

%.o: %.S
@echo " CC " $@
$(GCC) $(CFLAGS) $@ $<

else

build:
@echo "You have to run 'make config' first"
exit 0

endif

Nun bekomme ich die Meldung, dass das Skript es nicht schafft, dass aus einer *.c-Datei eine *.o-Datei wird.
Woran liegt es, dass er die Wildcards nicht trifft?

70

Softwareentwicklung / Makefile Erweiterung von Variablen

« am: 17. September 2011, 19:04 »

Hallo zusammen,

ich habe ein Problem mit meinen Makefiles.
Derzeit versuche ich folgendes Makefile in den Kernel einzubauen:

Code: [Auswählen]

KERNEL:=kernel lib
SRC:=$(shell find $(KERNEL) -type f -name '*.c')
CFLAGS:=-Wall -Wextra -nostdinc -fno-zero-initialized-in-bss -fno-builtin \
-fstrength-reduce -fomit-frame-pointer -finline-functions \
-fno-stack-protector -Iinclude -lgcc -MMD -O2 -g
LDFLAGS:=-Iinclude -Map kernel.map -nostdlib -O2

build:
ifneq ($(shell find . -type f -name '.config'),)

ifeq ($(shell grep ARCH .config), CONFIG_ARCH_X86_32)
CFLAGS+="-m32 -march=i686"
LDFLAGS+="-Tarch/x86/linker.ld -melf_i386 -o"
KERNEL+="arch/x86"
endif

@echo $(CFLAGS)
@echo $(LDFLAGS)
@echo $(KERNEL)

else
@echo "You have to run 'make config' first"
exit 0
endif

Wenn ich den Code so ausfuehre, laeuft der Code ohne fehler durch, aber die Echos geben nicht die erweiterten Variablen aus. Habe es schon ueberprueft, der Code laeuft den Pfad der Erweiterungen ab.

Woran kann das liegen?

Danke.

Gruss,
rizor

71

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 06. September 2011, 12:00 »

Was mir bei dlmalloc aufgefallen ist... das ist doch so eine Art SLAB-Allocator, oder?
Davon würde ich ganz gerne weggehen, da mir da der Speicheroverhead zu groß ist.
Der Kernel soll natürlich auch einen haben, aber halt wirklich nur für feste Allokationen.

72

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 06. September 2011, 10:02 »

Stimmt, das ist ja leider das allgemeine Problem.
Es tritt sich halt immer leichter von oben nach unten .

73

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 06. September 2011, 09:37 »

Naja, du als Entwickler bist dazu verpflichtet dich über die Patentlage zu informieren.
Kleinere Firmen sind vermutlich kaum im Interesse eines großen Konzerns.
Der geht ja mit jeder Patentklage das Risiko ein, dass ihm Patente aberkannt werden (z.B. Oracle vs. Google).
Erst wenn die Firmen größer werden, kriegen sie ärger (z.B. HTC)

74

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 06. September 2011, 09:30 »

Das Problem besteht bei allen Projekten, die irgendwie in den USA vertreten sind.
Wenn nur etwas Code davon in die Staaten kommt, könnte der Programmierer bei der Einreise Probleme bekommen.

Daran dachte ich zwar auch, aber dann gilt das für alles was im Internet ist oder?

Richtig. Das ist ja grade das bekloppte an diesen Softwarepatenten.

Hier ist einer der Artikel. Ich weiß nicht, ob es genau der war, aber er beschreibt das Ding mit Linux recht gut.
http://www.welt.de/wirtschaft/webwelt/article873934/Microsoft_klagt_ueber_Linux_Patentverstoesse.html

75

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 05. September 2011, 23:28 »

Allerdings würde ich auch mal sagen, dass das ganze für ein Hobby OS eher uninteressant ist, für Linux dürfte das schon problematisch werden (warum eigentlich?).

Das Problem besteht bei allen Projekten, die irgendwie in den USA vertreten sind.
Wenn nur etwas Code davon in die Staaten kommt, könnte der Programmierer bei der Einreise Probleme bekommen.

Für Linux gilt das ganze natürlich auch.
Es wird sogar angenommen, dass Linux gegen mehrere Patente verstößt.
Habe da mal eine Artikel drüber gelesen, habe ihn nur leider nicht auf die Schnelle gefunden.

76

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 04. September 2011, 23:42 »

Da ich endlich wieder ins Forum kann, will ich auch mal meinen Senf dazu beitragen.

Ich benutze für etwas ähnliches genau 2 AVL Bäume. In einem wird alles nach der Größe sortiert (malloc()) und in dem anderen, alles nach der Adresse (free()).
Um das von dir beschriebene Problem zu umgehen, besteht jede Node aus dem Baum mit der Größe aus einer Liste wo alle Objekte drin sind, die die gleiche Größe haben. Damit ist der Baum auch so klein wie möglich. Das kann im worst-case schonmal richtig was ausmachen. Stellt euch einfach vor ihr habt verdammt viele Elemente drin und weil ihr keine Listen verwendet, müsst ihr den Baum erst "ewig" durchsuchen obwohl ihr eigentlich nur 2 oder 3 verschiedene Größen habt.

Ob nun AVL oder RB ist so eine Sache, kommt immer auf das Anwendungsgebiet drauf an. Ich nutze das obige z.B. für meinen VMM, damit ich Blöcke innerhalb des Adressraumes finden kann und auch wieder mergen kann.
Für genau diesen Fall gibt es ein Paper wo man mehrere Bäume miteinander verglichen hat (AVL, RB, Splay und Binary) und rausgekommen ist, das es auf die Anwendung ankommt, aber sich RB und AVL nicht wirklich viel nehmen. Allerdings waren die Splay-Trees sehr interessant, da sie meistens nicht schlechter als RB und AVL waren, aber wenn sie besser waren dann deutlich.
Ob das allerdings heute noch gilt, wenn man von ALRS (oder wie auch immer das hieß -> erik) ausgeht, denke ich eher nicht.

Genau die Idee hatte ich auch schon.
Ich habe mir nun auch noch überlegt, ob ich es vllt noch lock-free schaffe.
Dabei ist mir halt leider aufgefallen, dass es ein Patent gibt, dass einen lock-free Baum beschreibt...

Um das von dir beschriebene Problem zu umgehen, besteht jede Node aus dem Baum mit der Größe aus einer Liste wo alle Objekte drin sind, die die gleiche Größe haben.

Die Idee kam mir zwar auch, ich hatte aber den Performancevorteil nicht gesehen. Klingt ansonsten sinnvoll.
Die einzige Frage ist nur, wie löscht du aus dem anderen Baum dann was (wenn es in dem einen gerade gelöscht wurde und man die Änderungen nachziehen muss)? Links von einem in den anderen Baum? Oder taucht das Problem garnicht auf (würde mich irgendwie verwundern).

Das Problem taucht natürlich auf, aber man kann das ja durch direkte Links lösen.
Dadurch erspart man sich sogar das Suchen, da du ja weißt, wo du löschen musst.

Darum habe ich mir überlegt als Header einen Baum orientiert anhand von Adressen zu verwenden und dann woanders den Baum anhand von Größen habe möchte.
Das Problem daran ist halt, dass wenn ich häufiger malloc als free verwende, dass mir bei der Idee die Cache-Lokalität verloren gehen kann.
Vermutlich müsste der Kernel mal Statistiken über die Allokationsgrößen führen.
Dadurch könnte man ermitteln, ob man darunter noch einen Cache legen kann, der in konstanter Zeit speicher allozieren kann und man somit den Cache ausnutzen kann.
Also im Prinzip ein SLAB-Allocator mit variablen Speicherbereichen.
Das dürfte aber vermutlich nur mit einem Mikrokernel gehen, oder?

77

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 04. September 2011, 16:11 »

Ist es denn garantiert, dass ich trotzdem uch nach dem entfernen eines Knoten trotzdem einen bestimmten Knoten finden kann?
Also z.B. bei einer zweiten Allokation mit der selben Größe.
Oder kann es passieren, dass mir auch Knoten "verloren" gehen?

Mirfällt zwar kein Szenario ein, das mir Knoten "verbirgt", aber ich bin mir nicht hundertprozentig sicher.

78

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 04. September 2011, 15:05 »

Wieso verändert die Rotation nicht die inorder, wenn man identische Schlüssel zulässt?

Füge einfach mal dreimal den Schlüssel 1 ein.
Nach einer einfachen Rechtsrotation erhalte ich folgenden Baum:
     1
   /   \
 1      1

Somit ist das Kriterium <= hinfällig für den linken Teilbaum, oder?

79

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 04. September 2011, 01:10 »

dann nimm doch einfach die Adresse als zusätzliches Sortierkriterium. Wenn Du einen Speicherbereich mit einer bestimmten Größe suchst ist Dir doch sicher egal welcher es genau ist (solange die Größe passt) so das es keine Rolle spielt welchen Du als erstes im Baum findest und diesen einfach nimmst.

Man sortiert halt das Paar (Größe, Adresse) wie folgt (Die Standardordnung die man so auf Paaren einführt): p1 < p2 gdw. (p1.größe < p2.größe oder (p1.größe == p2.größe und p1.adresse < p2.adresse)). Dann hast du sofort eine totale Ordnung und eindeutige Schlüssel, wobei der Schlüssel jetzt natürlich das Tupel (Größe, Adresse) ist. Wenn du nur nach der Größe suchst, kannst du das natürlich auch weiterhin genauso wie normal machen (Indem man nur nach Größe sucht). Aber jetzt kannst du auch einen Lookup auf einen eindeutig identifizierten Knoten machen (falls du aus deinem "Adressen-Baum" was gelöscht hast und die Änderung jetzt auch in dem "Größe-Baum" machen willst).
Ich seh damit ehrlichgesagt überhaupt kein Problem... Ich sehe sogar nichtmal das Problem ohne die eindeutige Identifikation der Knoten (wenn man zB Zeiger von einem Baum in den anderen hat, falls das das Problem ist, welches du siehst? Oder wann genau wird es denn relevant, dass man exakt in einem konkreten Knoten landet im "Größe-Baum" und nicht nur an einem "der größer/kleiner/gleich groß ist wie"?)

Der Aufbau des Baumes ist ja auch nicht mein Problem. Das Problem habe ich nur bei den Rotationen.
Da geht mir dann die Sortierung verloren (Knoten1 == Knoten2 -> Knoten1 links von Knoten 2). Es kann passieren, dass nach der Rotation Knoten2 rechts von Knoten1 liegt (rechts-rotation), wobei er eigentlich links davon liegen müsste.
Somit müsste ich ja beide Kindknoten untersuchen.

Sidenote: Für was brauchst du denn den "Adressen-Baum"?

Für ein möglichst schnelles shrinken/mergen von Knoten.

80

OS-Design / Re:Optimale Baumstrukturen fuer malloc/free

« am: 03. September 2011, 19:54 »

Das Verfahren, das du beschrieben hast ist aber nicht gut für das Suchen.
Die Idee hatte ich auch, aber durch die Balancierungen weiß ich nicht mehr, wo ich nachschauen muss um ein passendes Element zu finden.
Das ist mein größtes Problem.
Es kann dann durchaus passieren, dass der Baum am Ende alles andere als sortiert ist.
Ich weiß nicht, wie ich das lösen soll, es sei denn, ich nehme einen nicht balancierten Baum. Der ist mir allerdings nicht performant genug.
Wie wird das Problem denn von anderen Speicherverwaltungen gelöst?
Habe leider keine Artikel oder Paper dazu gefunden.