Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Themen - rizor

Seiten: 1 [2] 3 4
21
OS-Design / SLAB-Allocator als Basis fuer kmalloc?
« am: 18. May 2011, 21:52 »
Nabend zusammen,

ich habe jetzt einen fertigen SLAB-Allocator, der stark auf parallelen Zugriff durch feingranulares Locking optimiert ist. Nun wollte ich mir kmalloc schreiben und habe mir ueberlegt, ob es nicht sinnvoll waere kmalloc nur als eine Art Wrapper zu verwenden, der anhand der Groessen entscheidet aus welchem SLAB der Speicher geholt werden soll. Macht sowas sinn? Das erhoeht natuerlich den Verwaltungsoverhead, da ich mehrere Slabs fuer ein kmalloc brauche. Ausserdem erlaubt mein Kernel Speicherallokationen aus bestimmten bereichen (low- oder highmem). Ausserdem wird noch zwischen normalem und boot Speicher unterschieden. Nach dem Bootvorgang wird der gesamte boot Speicher freigegeben, damit der Kernel so wenig Speicher wie moeglich verschwendet. Somit muesste ich auf jeden Fall drei SLABS anlegen, wobei das noch nicht reichen duerfte. Ansonsten muss jeder SLAB grosse Bloecke verteilen, die zu einen starken inneren Fragmentierung fuehren. Also brauchte ich 3 * x SLABS.
Ist das noch praktikabel?

Habe auch lockless Allokation-Algorithmen gefunden, die sind aber vermutlich nicht viel optimaler.

Gruss,
rizor
22
Morgen zusammen,

ich habe ein Problem mit meinem Kernel. Ich habe mir einen SLAB-Allocator geschrieben, der momentan Slabs fuer allozierbare Caches/Slabs/Objekte erstellt, damit selbst der SLAB-Aufbau moeglichst parallel stattfinden kann. Momentan berechne ich die Anzahl an Objekten, die ich benoetige, damit ich den Speicher moeglichst effektiv verwalten kann.
Meine Formel funktioniert soweit, verschwendet zum Teil nur 300 Byte. Um das zu verhindern, optimiere ich den Speicher danach noch von Hand. Leider spinnt der Kernel, sobald ich ihn mit diesen Optimierungen kompiliere. Woran kann das liegen?

Ohne die Optimierung:
inline void __preboot_text slab_struct_count(size_t* objs, size_t* chunks,
size_t size, size_t alloc) {
size_t tmp;

tmp = alloc - sizeof(struct slab_cache);
tmp /= sizeof(struct slab_chunk) + (sizeof(struct slab_object) + size) *
CONFIG_OBJ_PER_CHUNK;

*chunks = tmp;
*objs = tmp * CONFIG_OBJ_PER_CHUNK;
}

Mit der Optimierung:
inline void __preboot_text slab_struct_count(size_t* objs, size_t* chunks,
size_t size, size_t alloc) {
size_t tmp;
int diff;

tmp = alloc - sizeof(struct slab_cache);
tmp /= sizeof(struct slab_chunk) + (sizeof(struct slab_object) + size) *
CONFIG_OBJ_PER_CHUNK;

*chunks = tmp;
*objs = tmp * CONFIG_OBJ_PER_CHUNK;

diff = alloc - sizeof(struct slab_cache) - tmp * sizeof(struct slab_chunk) -
(tmp * CONFIG_OBJ_PER_CHUNK) * sizeof(struct slab_object);

//optimize the memory
if(diff - sizeof(struct slab_chunk) >= sizeof(struct slab_object) + size) {
diff -= sizeof(struct slab_chunk);
*chunks += 1;

while(diff >= (int)(sizeof(struct slab_object) + size)) {
diff -= sizeof(struct slab_object) + size;
*objs += 1;
}
}
}

Danke.

Gruss,
rizor
23
Offtopic / Sched-Infos
« am: 13. April 2011, 19:31 »
Hi Leute,

ich habe ein Problem.
Weisz einer von euch, wie ich unter Linux die reine CPU-Zeit bekomme, nachdem ein Prozess terminierte?
Ich kriege zur Laufzeit ja die Jiffies ueber das ProcFS, aber das reicht mir nicht.
Das verfaelscht meine Ergebnisse.
Ich habe kein Problem mir dazu ein Programm zu schreiben oder ein Skript.
Ich habe leider momentan keinen Ansatz.

times() bringt mir glaub ich nicht die reine CPU-Zeit, oder?

Danke.

Grusz,
rizor
24
Lowlevel-Coding / BIOS-Interrupts
« am: 02. April 2011, 19:12 »
Hallo zusammen,

ich habe momentan ein Problem mit meinen BIOS-Interrupts.
Mein System soll den Speicher selbst bestimmen durch 0xe820.
Habe mir dazu Code geschrieben, der in den unreal-mode springt und wieder in den PM springt.
Den Code habe ich gegen Adresse 0x7000 gelinkt und lade ihn auch an die Stelle.
In meinem Kernel rufe ich folgenden Assembler-Befehl:
call *0x7000
Leider laedt er nicht 0x7000 in EIP sondern den Inhalt von 0x7000.
Wenn ich es mit
call (0x7000)
probiere, kommt nichts sinnvolles bei raus. Das was dann in EIP steht, kann ich in meinem Code nicht finden.

Wie sieht er richtige Befehl aus?

Danke.

Grusz
rizor
25
OS-Design / relocatable kernel
« am: 10. March 2011, 23:51 »
Hi,

ich habe mir mal Gedanken darueber gemacht, wie man am effektivsten einen Kernel schreiben kann, den man bei aktivem Paging auch komplett an eine andere Adresse legen kann.
Was muss man dabei denn alles beachten?

Auf jeden Fall muss man den Stack bearbeiten. Dabei faellt mir auf auf, dass es auch schief gehen kann, oder? Wenn auf dem Stack ein Wert steht, der in den Code-Bereich passt, obwohl es keine Adresse ist.
Dann muessen auch noch die aufgebauten Datenstrukturen umgelegt werden, oder?
Unter C ist das noch recht simpel, aber unter C++ ist das ungemein schwerer, oder?

Hat sich einer von euch schon mal daran versucht?

rizor
26
Lowlevel-Coding / GPF ohne Subsystems, Double Fault mit Subsystems
« am: 26. February 2011, 00:13 »
Hi zusammen,

ich habe gerade ein Problem mit meinem Kernel. Es ist mir aufgefallen, als ich Interrupts aktiviert habe und der Kernel mit einem Double Fault aussteigt. Dann habe ich erst einmal alle Subsysteme (Memory, scheduler, process-manager, etc.) auskommentiert und an sich nur noch den Code drin, der meine Konsole leert, eine Ausgabe macht und die Interrupts aktiviert. Dann taucht in einer Endlosschleife ein GPF auf. Kann mir nicht erklaeren wo der herkommt, da alle Subsysteme starten, solange die Interrupts deaktiviert sind.
Mein IDT und mein GDT sollten nicht das Problem sein, da es auch einen Double Fault gibt, wenn nur die abgeschaltet sind.

Habt ihr Ideen, die ich mal probieren kann?
Ach ja, Bochs und Qemu geben keine Aufaelligkeiten von sich.

rizor
27
Lowlevel-Coding / GRUB Error7
« am: 22. February 2011, 00:16 »
Nabend zusammen,

ich habe ein Problem mit Grub. Qemu winkt den Code durch.
Ich habe meinen Kernel gebaut, der komplett oberhalb der 1MB Grenze liegt.
Leider ist Grub da anderer Meinung.

Hier mal mein Linker-Skript:
ENTRY(_start)
OUTPUT(elf32-i386)
OUTPUT_ARCH(i386:i386)

SECTIONS
{
. = 0x100000;

__kernel_entry = .;
__init_entry = .;
__init32_entry = .;
.init32 0x100000 : {
*(.multiboot)
*(.init32_text)
*(.init32_data)
}
__init32_end = .;
__init_end = .;

. = ALIGN(0x1000);

__ro_data_entry = .;
.text : {
*(.text)
*(.rodata)
}
__ro_data_end = .;

. = ALIGN(0x1000);

__rw_data_entry = .;
.data : {
*(.data)
}

.bss : {
*(COMMON)
*(.bss)
}
__rw_data_end = .;
__kernel_end = .;

/DISCARD/ : { *(.comment) }
}

Hier noch ein paar Ausgaben (readelf und objdump):

rizor-kernel/rizor-kernel.krn:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .init32       00004c58  00100000  00100000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, CODE
  1 .text         00009328  00105000  00105000  00006000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .data         00000054  0010f000  0010f000  00010000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00005c68  0010f060  0010f060  00010054  2**5
                  ALLOC
  4 .debug_abbrev 00002a7c  00000000  00000000  00010054  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   0000c1ea  00000000  00000000  00012ad0  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_line   000031d6  00000000  00000000  0001ecba  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_loc    000027bb  00000000  00000000  00021e90  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_pubnames 00001df3  00000000  00000000  0002464b  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubtypes 00001ecd  00000000  00000000  0002643e  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_aranges 00000588  00000000  00000000  00028310  2**3
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_str    00003063  00000000  00000000  00028898  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_frame  00001a04  00000000  00000000  0002b8fc  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_ranges 00000298  00000000  00000000  0002d300  2**0
                  CONTENTS, READONLY, DEBUGGING

There are 18 section headers, starting at offset 0x2d654:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .init32           PROGBITS        00100000 001000 004c58 00 WAX  0   0 32
  [ 2] .text             PROGBITS        00105000 006000 009328 00  AX  0   0  4
  [ 3] .data             PROGBITS        0010f000 010000 000054 00  WA  0   0 32
  [ 4] .bss              NOBITS          0010f060 010054 005c68 00  WA  0   0 32
  [ 5] .debug_abbrev     PROGBITS        00000000 010054 002a7c 00      0   0  1
  [ 6] .debug_info       PROGBITS        00000000 012ad0 00c1ea 00      0   0  1
  [ 7] .debug_line       PROGBITS        00000000 01ecba 0031d6 00      0   0  1
  [ 8] .debug_loc        PROGBITS        00000000 021e90 0027bb 00      0   0  1
  [ 9] .debug_pubnames   PROGBITS        00000000 02464b 001df3 00      0   0  1
  [10] .debug_pubtypes   PROGBITS        00000000 02643e 001ecd 00      0   0  1
  [11] .debug_aranges    PROGBITS        00000000 028310 000588 00      0   0  8
  [12] .debug_str        PROGBITS        00000000 028898 003063 01  MS  0   0  1
  [13] .debug_frame      PROGBITS        00000000 02b8fc 001a04 00      0   0  4
  [14] .debug_ranges     PROGBITS        00000000 02d300 000298 00      0   0  1
  [15] .shstrtab         STRTAB          00000000 02d598 0000ba 00      0   0  1
  [16] .symtab           SYMTAB          00000000 02d924 001e40 10     17  71  4
  [17] .strtab           STRTAB          00000000 02f764 001a4f 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)

Was kann GRUB dazu bewegen mir diese Meldungen zu geben.
Kann es an den Debug-Sektionen liegen?

Danke.
28
OS-Design / Mapping verwalten
« am: 26. January 2011, 10:07 »
Hi zusammen,

wie habt ihr euer Mapping verwaltet?
Damit ist nicht das normale malloc gemeint, sondern wenn ein Prozess bestimmte Speicherbereiche gemappt haben möchte.
Momentan mappt mein Kernel einfach so ohne zu prüfen, aber das ist ja sehr ungünstig.
Habt ihr da recht performante Ideen?

Gruß,
rizor
29
Softwareentwicklung / Dateiformate
« am: 24. January 2011, 23:35 »
Hi zusammen,

ich bin gerade dabei mir ein eigenes Dateiformat zu überlegen, dass dann mein Kernel unterstützen soll.
Welches Dateiformat würdet ihr als Ausgangssituation empfehlen?
Damit meine ich, dass der Code fertig gelinkt sein soll. Das Format braucht Informationen über alle vorhandenen Sektionen, damit ich die Datei entsprechend konvertieren kann.
Ich könnte natürlich das Elf-Format übersetzen, aber gibt es da noch einfachere, mit ensprechenden Informationen?

Gruß,
rizor
30
Lowlevel-Coding / Kernel-Thread und normale Threads
« am: 20. January 2011, 22:15 »
Nabend zusammen,

ich habe mal eine Frage zu den Unterschieden zwischen den beiden Threadarten.
Zum einen muss ich die Register (cs,ss) unterschiedlich setzen.
Der Kernel-Thread braucht auch seinen eigenen Stack, oder?
Kann ich den genau so laden, wie einen normalen Stack, also über esp = stack in meinem CPU dump?

Danke.

Gruß,
rizor
31
OS-Design / Aufräumen von Threads
« am: 19. January 2011, 15:54 »
Hallo zusammen,

mein Kernel soll Threads unterstützen und nun mache ich mir Gedanken, wie ich einen Thread am besten aufräume.
Wie habt ihr das gemacht?
Ich habe mir überlegt, dass jeder Thread eine memmap erhält, die ich dann aufräume.
Nun habe ich aber das Problem mit dem malloc. Wenn der Thread speicher anfordert, wird der in meinen Malloc-Baum eingegliedert. Nun kann ich aber nicht einfach die memmap aufräumen, da es ansonsten echt ungünstig werden kann. Wie lässt sich sowas gut lösen?
Eine Möglichkeit wäre, dass jeder thread seinen eigenen malloc-baum bekommt, das finde ich aber nicht wirklich gut.

gruß,
rizor
32
Softwareentwicklung / GCC: Include loop wird nicht aufgelöst
« am: 19. January 2011, 01:34 »
Nabend zusammen,

ich habe ein Problem mit dem GCC.
Ich habe mir einen Spinlock definiert, der recht häufig verwendet wird.
Dieser wird zum Beispiel für meine vmm_contexts verwendet.
Bisher lief alles einwandfrei.
Wenn ich nun aber den vmm_context in meinen PCB eintrage, erhalte ich folgende Ausgabe:
    CC lib/mutex/spinlock.c
In file included from include/process/process.h:38
                        from include/kernel/mutex.h:37
                        from lib/mutex/spinlock.c:35
include/mem/vmm.h:64: Error: expected specifier-qualifier-list before >>spinlock_t<<
Mir ist klar, dass es sich da um eine zirkuläre Abhängigkeit handelt, die er nicht auflösen kann.
Ich frage mich nur, warum es jetzt auf einmal auftaucht.

Wie kann ich das Problem beheben?

Gruß,
rizor
33
Lowlevel-Coding / x86 SMP
« am: 13. January 2011, 00:21 »
Hi zusammen,

ich bin soweit, dass ich meinen Scheduler bedenkenlos schreiben kann.
Der Scheduler soll bei der Initialisierung alle anderen CPUs starten, damit das System möglichst schnell
alle CPUs verwendet.

Wie finde ich heraus, wie viele CPUs das System enthält?
Habe etwas mit der Floating Point Structure gefunden, werde daraus allerdings nicht schlau.

Was muss ich beim Booten der anderen CPUs beachten?
Sind die noch im RM?
Falls ja, müsste ich mir also erst Code schreiben, der sie dann in den PM holt, dann Speicher für den Stack besorgen und ab dann müssten sie laufen, oder (TSS fehlt auch noch)?

Gibt es sonst noch Probleme, die ich beachten muss?
Also mein Kernel ist von Grund auf für den SMP-Support designed.

Danke.

Gruß,
rizor
34
Lowlevel-Coding / Stack wird verändert....
« am: 19. July 2010, 18:02 »
Hallo,

ich habe ein Problem mit meinem Stack.

Folgende Funktion verändert den Stack:
int kmesg_putc(char c)
{
#if defined(CONFIG_SERIAL_KMESG)
error_p errno;
#endif /* CONFIG_SERIAL_KMESG */

kmesg_buf[kmesg_pointer++] = c;
#if defined(CONFIG_CONSOLE_KMESG)
con_put_char(c);
#endif /* CONFIG_CONSOLE_KMESG */
#if defined(CONFIG_SERIAL_KMESG)
rs232_send(0 , c , errno);
#endif /* CONFIG_SERIAL_KMESG */

return 1;
}
Der Befehl, der den Stack schmeißt, ist komischer Weise "return 1;".

Vor dem Befehl sieht der Stack wie folgt aus:
#0  kmesg_putc (c=91 '[') at lib/kprintf/kmesg.c:290
#1  0x0010280f in kaprintf (msg=0x102fde "PANIC] ", args=0x1070c8 "\370p\020")
    at lib/kprintf/kmesg.c:484
#2  0x00102855 in kprintf (msg=0x102fdd "[PANIC] ") at lib/kprintf/kmesg.c:504
#3  0x00102977 in panic (
    msg=0x102e30 "multiboot-magic-code is incorrect (expected: %#x , read: %#x)") at lib/kprintf/kmesg.c:559
#4  0x0010044f in init (mb_magic=38144, mb_struct=0xf000ff53) at init/init.c:69
ESP hat den Wert: 0x107024

Nach dem Aufruf sieht der Stack so aus:
#0  kmesg_putn (value=0) at lib/kprintf/kmesg.c:299
#1  0x00000000 in ?? ()
ESP hat den Wert: 0x107024

Woran kann das liegen?

Danke.

Gruß,
rizor

35
Lowlevel-Coding / BDA in Qemu fehlerhaft?
« am: 19. July 2010, 09:02 »
Hallo,

kann es sein, dass Qemu die BDA nicht richtig setzt?
Habe mir ein bda-struct aufgebaut, dass 0x400 ausliest und dort steht nur 0 drin.
Liegt das an meinem Kernel oder macht Qemu da irgendwelchen Mist?
Habe das struct so aufgebaut, wie es im Wiki steht.
36
Lowlevel-Coding / Kein Multiboot trotz Linkereintrags
« am: 15. July 2010, 12:00 »
Hallo,

ich habe ein Problem mit meinem Linker.
Ich habe mir zwei eigene Sektionen definiert (preboot und boot) und möchte in die boot-Sektion den Multiboot-Header geladen haben.
Leider funktioniert das nicht so ganz und ich weiß nicht warum.

Hier mein Linker-Skript:
/* the linker script to link the kernel */
ENTRY(_start) /* the entry-point of the kernel */
OUTPUT_FORMAT(elf32-i386) /* the output-format */

/* some constants to link the code correctly */
ALIGNMENT = 0x1000; /* the alignment of the sections */
PHYS_ADDRESS = 0x100000; /* the physical address of the kernel */
VIRT_ADDRESS = 0x100000; /* the virtual address of the kernel */
REMAP_OFFSET = VIRT_ADDRESS - PHYS_ADDRESS; /* the offset between physical and virtual addresses */

/* define the different sections of the kernel */
SECTIONS
{
. = VIRT_ADDRESS; /* move the kernel to the correct start-address */

__kernel_virt_entry = .; /* the beginning with virtual addresses */
__kernel_phys_entry = . - REMAP_OFFSET; /* the beginning with physical addresses */

.preboot : AT(ADDR(.preboot) - (REMAP_OFFSET + 0x1000))
{
__preboot_entry = .; /* the entry-symbol to get the space of the preboot-section */
*(.preboot)
__preboot_end = .; /* the end-symbol to get the space of the preboot-section */
}

. = ALIGN(ALIGNMENT);

.boot : AT(ADDR(.boot) - REMAP_OFFSET)
{
__boot_entry = .; /* the entry-symbol of the boot-section */
*(.boot)
__boot_end = .; /* the end-symbol of the boot-section */
}

. = ALIGN(ALIGNMENT);

.init : AT(ADDR(.init) - REMAP_OFFSET)
{
__init_entry = .; /* the entry-symbol of the init-section */
*(.init)
__init_end = .; /* the end-symbol of the init-section */
}

. = ALIGN(ALIGNMENT);

.text : AT(ADDR(.text) - REMAP_OFFSET)
{
__ro_data_entry = .; /* the entry-symbol of the read-only-section */
*(.text)
*(.rodata)
__ro_data_end = .; /* the end-symbol of the read-only-section */
}

. = ALIGN(ALIGNMENT);

.data : AT(ADDR(.data) - REMAP_OFFSET)
{
__rw_data_entry = .; /* the entry-symbol of the read-write-sections */
*(.data)
*(.bss)
__rw_data_end = .; /* the end-symbol of the read-write-sections */
}

. = ALIGN(ALIGNMENT);

__kernel_phys_end = . - REMAP_OFFSET; /* the end of the physical addresses */
__kernel_virt_end = .; /* the end of the virtual addresses */
}

Hier meine Multiboot-Datei:
.section .boot

// the following flags are every time set
#define MB_MAGIC 0x1badb002
/*
 * MB_FLAGS[0] == load modules 4k-aligned
 * MB_FLAGS[1] == calculate mbs_mem_lower,mbs_mem_upper and mbs_mmap_length, mbs_mmap_addr if possible
 * MB_FLAGS[2] == load some informations about the video-mode into the multiboot-structure
 * MB_FLAGS[16] == calculates some informations about the kernel-image
 */
#define MB_FLAGS 0x8007
#define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)
// the following flags are defined, if MB_FLAGS[16] is set
#define MB_HEADER_ADDR 0x0
#define MB_LOAD_ADDR 0x0
#define MB_LOAD_END_ADDR 0x0
#define MB_BSS_END_ADDR 0x0
#define MB_ENTRY_ADDR 0x0
// the following flags are defined, if MB_FLAGS[2] is set
#define MB_MODE_TYPE 0x0
#define MB_MODE_WIDTH 0x0
#define MB_MODE_HEIGHT 0x0
#define MB_MODE_DEPTH 0x0

.align 4
.int MB_MAGIC
.int MB_FLAGS
.int MB_CHECKSUM
.int MB_HEADER_ADDR
.int MB_LOAD_ADDR
.int MB_LOAD_END_ADDR
.int MB_BSS_END_ADDR
.int MB_ENTRY_ADDR
.int MB_MODE_TYPE
.int MB_MODE_WIDTH
.int MB_MODE_HEIGHT
.int MB_MODE_DEPTH

Wenn ich mir nun meine boot-Sektion mir readelf oder objdump anschaue, steht dort nur sinnloses Zeug.
Ausgabe von objdump:
Disassembly of section .boot:

00100000 <__boot_entry>:
  100000:       02 b0 ad 1b 07 80       add    -0x7ff8e453(%eax),%dh
  100006:       00 00                   add    %al,(%eax)
  100008:       f7                      (bad) 
  100009:       cf                      iret   
  10000a:       51                      push   %ecx
  10000b:       e4 00                   in     $0x0,%al

mbchk sagt natürlich, dass es keine Multiboot-Header finden konnte.

Woran kann das Problem liegen?

Danke.

Gruß
rizor
37
Lowlevel-Coding / kontrolliert zurück in den 16bit-Modus
« am: 14. April 2010, 16:48 »
Nabend zusammen,

ich möchte, dass mein System zurück in den realmode springt, dort arbeitet und dann wieder zurück kommt.
Dabei möchte ich nicht zwei Dateien laden, sondern einfach 16-bit code und 32-bit code zusammenpacken, falls das geht.
Danach soll der 16-bit Code unter die 1MB Grenze geladen werden und dann soll der Code ausgeführt werden.
Ist das möglich?

Danke.

Gruß
rizor
38
Softwareentwicklung / GDB wird von Qemu ignoriert
« am: 17. March 2010, 22:51 »
Nabend zusammen,

ich habe mir die aktuelle Qemu-Version aus den Quellen gebaut (0.12.3).
Nun starte ich meinen kernel mit -kernel...
Der Kernel wird auch gestartet und führt seinen Code aus, allerdings klappt das mit dem GDB nicht so ganz.
Wenn ich im GDB einen Breakpoint setze und dann c eingeben, damit Qemu aus dem Sleep-Status erwacht, wird der Breakpoint überrannt.
Das klappt erst, wenn ich mit SIGINT den Kernel stoppe, dann kann ich im single-step-modus den Code untersuchen.
Ich weiß nicht woran das liegt.
Hat einer von euch damit schon Erfahrung?

Gruß,
rizor

PS: wie kann ich VNC abschalten und die Ausgabe wieder in einem Qemu-Fenster ausgeben?
39
Lowlevel-Coding / spinlocks
« am: 17. March 2010, 16:09 »
Hallo zusammen,

ich habe ein Problem mit meinen Spinlocks.
Der Code stellt fest, dass ein Bereich gelockt ist, obwohl er es nicht ist.
Woran kann das liegen?

#define LOCKED 1
#define UNLOCKED 0
typedef volatile uint32_t lock_t;

void lock(lock_t *lock){
    __asm__ __volatile__(
"mov %0 , %%ecx\n"
"loop: xor %%eax , %%eax\n"
"lock cmpxchg %%ecx , %1\n"
"jnz loop\n" : : "i"(LOCKED) , "m"(lock));
}
Habe mir auch lock angeschaut und der ist auf UNLOCKED gesetzt.

Kann mir nicht erklären, woran es scheitert.

gruß,
rizor
40
Offtopic / Shell-Script zur Verzeichnisanalyse
« am: 06. March 2010, 01:15 »
Nabend zusammen,

ich bin gerade dabei ein Shell-Script zu schreiben, dass mir eine Verzeichnisstruktur und alle Source-Files in dieser Struktur, die nicht in .nobuild stehen, in eine Datei einzutragen.
Das Script ruft sich selbst rekursiv aus.
Woran liegt es, dass es den Fehler unexpected operateor?

# parameters:
# 1. path to this shell-script

SRC=""
OBJ=""

for file in `pwd`; do
    # found the nobuild-file
    if [ $file == ".nobuild" ]; then
continue
    fi
    # found a source-file
    if [ \( -z "{$file##*.c}" -a %%file != ".c" \) -o \( -z "{$file##*.S}" -a %%file != ".S" \) ]; then
# the ".nobuild"-file exists
if [ -f ".nobuild" ]; then
    # the file could not be found in the ".nobuild"-file
    if [ $file != `grep "$file" .nobuild` ]; then
SRC="$SRC $file"
OBJ="$OBJ $file.o"
    fi
# the ".nobuild"-file does no exist
else
SRC="$SRC $file"
OBJ="$OBJ $file.o"
fi
continue
    fi
    # the file is a directory
    if [ -d $file ];then
# analyse the directory
cd $file
    sh "$1"
cd ..

# search the "file"-file and extend our SRC and OBJ
if [ -f "$file/file" ]; then
    SRC_2=`sed -ne '1p' "$file/file"`
    OBJ_2=`sed -ne '2p' "$file/file"`
    SRC="$SRC $SRC_2"
    OBJ="$OBJ $OBJ_2"
    rm -f "$file/file"
fi
    fi
done

Gruß,
rizor
Seiten: 1 [2] 3 4

Einloggen