Autor Thema: Struktur auf beliebigen Speicher anwenden  (Gelesen 52010 mal)

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #60 am: 03. February 2009, 16:47 »
hmm weiß keine ne Lösung?
In the Future everyone will need OS-64!!!

tarrox

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« Antwort #61 am: 03. February 2009, 16:57 »
Du musst auf die Addresse von kernel_end zugreifen und nicht auf das worauf es zeigt.
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

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #62 am: 03. February 2009, 17:10 »
hmm weiß keine ne Lösung?
Hey, wenn du Antwortzeiten von unter einer Stunde erwartest, komm ins IRC ;)
Dieser Text wird unter jedem Beitrag angezeigt.

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #63 am: 03. February 2009, 17:25 »
ich weiß die Antwort:

extern void kernel_end(void);
 :-D
In the Future everyone will need OS-64!!!

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #64 am: 03. February 2009, 17:32 »
Wo haste dir denn den Trick abgeschaut? :P
Dieser Text wird unter jedem Beitrag angezeigt.

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #65 am: 03. February 2009, 17:40 »
Wo haste dir denn den Trick abgeschaut? :P
bei Franck Ribery  :-P
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #66 am: 03. February 2009, 18:24 »
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.
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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #67 am: 03. February 2009, 18:43 »
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
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #68 am: 03. February 2009, 18:56 »
Zitat
Junge, nenn mich nicht Junge!
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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #69 am: 03. February 2009, 19:04 »
Zitat
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ä?

 :-o :? :-( :cry: :? :-o :x :? :-o
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #70 am: 03. February 2009, 19:29 »
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.
« Letzte Änderung: 03. February 2009, 19:31 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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #71 am: 03. February 2009, 20:32 »
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
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #72 am: 03. February 2009, 21:21 »
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.")
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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #73 am: 03. February 2009, 21:53 »
Zitat
Dann darf der Bootloader dich auch laden wenn er nicht mem_* füllen kann.
Mich darf er laden? oO besser nicht  :lol: 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
In the Future everyone will need OS-64!!!

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #74 am: 05. February 2009, 12:53 »
So, welche Größe hat __SIZE_TYPE__ eigentlich?

Und was ist der Unterschied zwischen const char *bla und char *bla?

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

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
« Letzte Änderung: 05. February 2009, 13:49 von bitmaster »
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #75 am: 05. February 2009, 14:36 »
So, welche Größe hat __SIZE_TYPE__ eigentlich?
sizeof(__SIZE_TYPE__)


Zitat
Und was ist der Unterschied zwischen const char *bla und 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.

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

Zitat
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

Zitat
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).
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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #76 am: 05. February 2009, 14:40 »
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
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #77 am: 05. February 2009, 14:44 »
Du darfst mit dem sehr wohl rechnen, aber es wird nicht das sein was du dir vorstellst. zB:
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:
T *t = 0;
t = (T*)((uintptr_t)t + x)
wobei x die Anzahl der Bytes ist die du weiter möchtest.
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

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #78 am: 05. February 2009, 14:48 »
Du darfst mit dem sehr wohl rechnen, aber es wird nicht das sein was du dir vorstellst. zB:
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:
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 (u32)boot_inf gehts. Aber trotzdem danke.

bitmaster
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #79 am: 05. February 2009, 14:50 »
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.
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

 

Einloggen