Thema: Struktur auf beliebigen Speicher anwenden

[bitmaster]

hmm weiß keine ne Lösung?

[tarrox]

Du musst auf die Addresse von kernel_end zugreifen und nicht auf das worauf es zeigt.

Code: [Auswählen]

u32int* pointer = (u32int*)kernel_end; //Du greifst auf den inhalt an der Addresse von Kernelende zu, das willst du ja nicht
u32int* pointer = &kernel_end; //der Pointer zeigt auf das Ende des Kernels

[Jidder]

hmm weiß keine ne Lösung?

Hey, wenn du Antwortzeiten von unter einer Stunde erwartest, komm ins IRC

[bitmaster]

ich weiß die Antwort:

Code: [Auswählen]

extern void kernel_end(void);
 

[Jidder]

Wo haste dir denn den Trick abgeschaut?

[bitmaster]

Wo haste dir denn den Trick abgeschaut?

bei Franck Ribery 

[bluecode]

Das mit dem Align auf 4K ist bei GRUB auf jeden Fall so. Bin mir nicht hundertprozentig sicher, ob es auch in der Spezifikation steht.

Steht da sehr wohl drin, wobei man dafür bit0 der Flags setzen muss, siehe Multiboot Specification.

[bitmaster]

Das mit dem Align auf 4K ist bei GRUB auf jeden Fall so. Bin mir nicht hundertprozentig sicher, ob es auch in der Spezifikation steht.

Steht da sehr wohl drin, wobei man dafür bit0 der Flags setzen muss, siehe Multiboot Specification.

Gut dass du das sagst Junge, das Flag war bei meinem Kernel nämlich gelöscht.

bitmaster

[bluecode]

Junge, nenn mich nicht Junge!

[bitmaster]

Junge, nenn mich nicht Junge!

Junge, was meinen die mit Bit1? Wenn keine mmap vorhanden ist, dass dann die mem-felder vorhanden sein müssen?hä?

 

[bluecode]

ehm... hä? Da steht, dass wenn du Bit 1 der Multiboot Header setzt, dass dann mindestens die mem_* Elemente der Multiboot Information Structure gültig sind (Anmerkung: ansonsten darf der Bootloader dein OS nicht laden) und falls der Bootloader fähig ist eine Memory-Map dir mit auf den Weg zu geben und noch dazu einen Memory-Map vorhanden ist (Anmerkung: über das BIOS), dann darf der Bootloader auch die mmap_* Elemente füllen.

[bitmaster]

ehm... hä? Da steht, dass wenn du Bit 1 der Multiboot Header setzt, dass dann mindestens die mem_* Elemente der Multiboot Information Structure gültig sind (Anmerkung: ansonsten darf der Bootloader dein OS nicht laden) und falls der Bootloader fähig ist eine Memory-Map dir mit auf den Weg zu geben und noch dazu einen Memory-Map vorhanden ist (Anmerkung: über das BIOS), dann darf der Bootloader auch die mmap_* Elemente füllen.

Ja das kann ich auch lesen. Und wenn Bit1 nicht gesetzt ist? Was ist dann anders?

bitmaster

[bluecode]

Dann darf der Bootloader dich auch laden wenn er nicht mem_* füllen kann. Die Flags in der Multiboot Header sagen einfach dem Bootloader was er mindestens tun muss um laden zu dürfen. ("The field `flags' specifies features that the OS image requests or requires of an boot loader.")
Die Flags in der Multiboot Information Structure hingegen sagen dir was der Bootloader wirklich getan hat. ("The first longword indicates the presence and validity of other fields in the Multiboot information structure. All as-yet-undefined bits must be set to zero by the boot loader. Any set bits that the operating system does not understand should be ignored. Thus, the `flags' field also functions as a version indicator, allowing the Multiboot information structure to be expanded in the future without breaking anything.")

[bitmaster]

Dann darf der Bootloader dich auch laden wenn er nicht mem_* füllen kann.

Mich darf er laden? oO besser nicht  die mem_* werden wohl eher "gefüllt" sein als die mmap_*. Bei meinem alten Notebook sind die mmap_* Felder z.B. nicht "gefüllt" aber die mem_* schon.

bitmaster

[bitmaster]

So, welche Größe hat

Code: [Auswählen]

__SIZE_TYPE__ eigentlich?

Und was ist der Unterschied zwischen

Code: [Auswählen]

const char *bla und

Code: [Auswählen]

char *bla?

Äh was gibts noch, hmm... später. 

bitmaster

EDIT: Ah, const ist sozusagen ein Schreibschutz, stimmts? Ich kann dann *bla nicht beschreiben. Zumindest wenn ich mein Buch richtig verstanden habe.

EDIT2: Bin gerade dabei die ersten Sachen für die libc zu machen (also strlen und so). Jetzt muss ich den kram ja mit gcc compilieren und habe dann eine *.o. Und weiter? Ich habe gesehen, dass das in Linux in ein *.a Archiv gepackt wird. Wie mache ich das? Und wie bringe ich gcc dazu, dass er dieses Archiv kennt, damit umgehen kann und es "immer" heranzieht. Also das Archiv müsste ich ja mit ar bauen können. Nur bei mir tut sich da nichts.

EDIT3: OK ich habs jetzt gebacken gekriegt mit dem Archiv. Aber wie sage ich dem gcc jetzt das er mit dem Archiv arbeiten soll?

thx

bitmaster

[bluecode]

So, welche Größe hat

Code: [Auswählen]

__SIZE_TYPE__ eigentlich?

sizeof(__SIZE_TYPE__)

Und was ist der Unterschied zwischen

Code: [Auswählen]

const char *bla und

Code: [Auswählen]

char *bla?

Ersteres ist ein Zeiger der auf etwas was über diesen Zeiger nicht (ohne Cast) verändert werden darf zeigt. Letzteres ist ein "normaler" Zeiger.

EDIT: Ah, const ist sozusagen ein Schreibschutz, stimmts? Ich kann dann *bla nicht beschreiben. Zumindest wenn ich mein Buch richtig verstanden habe.

Ja.

EDIT2: Bin gerade dabei die ersten Sachen für die libc zu machen (also strlen und so). Jetzt muss ich den kram ja mit gcc compilieren und habe dann eine *.o. Und weiter? Ich habe gesehen, dass das in Linux in ein *.a Archiv gepackt wird. Wie mache ich das? Und wie bringe ich gcc dazu, dass er dieses Archiv kennt, damit umgehen kann und es "immer" heranzieht. Also das Archiv müsste ich ja mit ar bauen können. Nur bei mir tut sich da nichts.

Beispiel: ar rc libc.a bla.o bla2.o

EDIT3: OK ich habs jetzt gebacken gekriegt mit dem Archiv. Aber wie sage ich dem gcc jetzt das er mit dem Archiv arbeiten soll?

Beim Linken nimmt man einfach das Archiv dazu (genauso wie eine Objektdatei auch).

[bitmaster]

bluecode: Ah cool, danke.

So noch was, ich habe einen Zeiger namens *boot_inf. Mittels boot_inf bekomme ich ja jetzt den Wert der Adresse. Aber wieso darf ich mit dem nicht rechnen bzw. kann ich das doch irgendwie erzwingen?

thx

bitmaster

[bluecode]

Du darfst mit dem sehr wohl rechnen, aber es wird nicht das sein was du dir vorstellst. zB:

Code: [Auswählen]

T *t = 0;
++t;
Unter der Annahme, dass T ein Typ der Größe s ist, ist nach diesem Codestück t = 0 + 1 * s = s, d.h. es wird anstatt ein Byte weiterzugehen einmal s Bytes weitergegangen.

Wenn du wirklich bytes weitergehen möchtest, dann macht man das so:

Code: [Auswählen]

T *t = 0;
t = (T*)((uintptr_t)t + x)
wobei x die Anzahl der Bytes ist die du weiter möchtest.

[bitmaster]

Du darfst mit dem sehr wohl rechnen, aber es wird nicht das sein was du dir vorstellst. zB:

Code: [Auswählen]

T *t = 0;
++t;
Unter der Annahme, dass T ein Typ der Größe s ist, ist nach diesem Codestück t = 0 + 1 * s = s, d.h. es wird anstatt ein Byte weiterzugehen einmal s Bytes weitergegangen.

Wenn du wirklich bytes weitergehen möchtest, dann macht man das so:

Code: [Auswählen]

T *t = 0;
t = (T*)((uintptr_t)t + x)
wobei x die Anzahl der Bytes ist die du weiter möchtest.

Äh ok, das mit dem inkrementieren/decrementieren habe ich schon gemerkt und in meinem Buch nachgelesen. Ich meinte mit "rechnen" jetzt aber was anderes. Aber ich habe es schon herausgefunden, mit

Code: [Auswählen]

(u32)boot_inf gehts. Aber trotzdem danke.

bitmaster

[bluecode]

Exakt dieses meinte ich mit uintptr_t... Zumindest wäre das der standard(konforme) Weg dies zu tun. Mit (u32) kriegst du im Longmode offensichtlich Probleme. Wie gesagt, Portabilität ist keine Eigenschaft einer (Hoch-)Sprache (edit: Aber erst Hochsprachen machen Portabilität möglich, falls jetzt wieder einer der Fließbandjungs kommt und nörgelt), sondern eher eine guten Codes.