Thema: nur 2 GiB trotz 64 bit

[Krox]

Nach langer Zeit dacht ich mir, mein altes OS wieder rauszukramen, wieder mit Grub, jetzt aber in echten 64 bit. Das Umschalten klappt auch ganz gut, doch danach soll ein Sprung in den Hochsprachen-Kernel folgen (nicht C/C++, sondern D... aber das ist hier egal^^).

Doch sobald ich diesen Kernel per ld-Script über die 2 GiB marke bewege, meldet der Linker:

Code: [Auswählen]

relocation truncated to fit: R_X86_64_PC32 against `KernelMain'Der Nasm-Sprungcode ist sehr einfach:

Code: [Auswählen]

extern KernelMain
[BITS 64]
jmp KernelMain

Achja, ich arbeite hier unter 64bit Ubuntu Linux, also sollte jeder Compiler/Linker nativ 64Bit benutzen.

kann mir jemand helfen?

[bluecode]

Achja, ich arbeite hier unter 64bit Ubuntu Linux, also sollte jeder Compiler/Linker nativ 64Bit benutzen.

Nativ ist so eine Sache, bei gcc/g++ gibt es verschiedene Codegenerationsmodi (aus dem gcc manual):

• -mcmodel=small: Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model.
• -mcmodel=kernel: Generate code for the kernel code model. The kernel runs in the negative 2 GB of the address space. This model has to be used for Linux kernel code.
• -mcmodel=medium: Generate code for the medium model: The program is linked in the lower 2 GB of the address space but symbols can be located anywhere in the address space. Programs can be statically or dynamically linked, but building of shared libraries are not supported with the medium model.
• -mcmodel=large: Generate code for the large model: This model makes no assumptions about addresses and sizes of sections. Currently GCC does not implement this model.

-mcmodel=large wird in gcc 4.3 afaik implementiert sein. Die Version sollte in den nächsten Wochen kommen, zumindest haben sie schon einen 4.3 branch erstellt und trunk für 4.4 freigegeben, wenn man der Mailingliste glauben schenken darf. So wie die gdc releases aber kenne wird es noch eine Ewigkeit dauern bis es den auch für 4.3 gibt... aber die Leute von gdc lassen nicht wirklich viel von sich hören...

Ob dir das bei gdc weiterhilft weiß ich jetzt leider nicht... und vom original D Compiler hab ich leider erst recht keine Ahnung...

[Krox]

hm, und ich dachte immer, diese 2GiB Beschränkungen wären nur bei 32 bit (bzw halt 31 bit + sign). Einen Effekt hat -mcmodel bei gdc für mein Problem nicht. Nagut, dann schiebe ich erstmal den Kernel halt etwas nach unten, auch wenn es mein Speicher-Layout auseinander wirft. Baer warum gibt es diese Begrenzungen überhaupt, wenn alle Zeiger (und auch size_t) 64 Bit breit sind?

Und nochwas: Wenn ich zur Laufzeit manche Daten nach weit oben mappe (48 Bit virtuelle Addressen sollte man schließlich ausnutzen ), funktioniert das?

achja, aber danke schonmal für die Hilfe...

[bluecode]

Baer [sic!] warum gibt es diese Begrenzungen überhaupt, wenn alle Zeiger (und auch size_t) 64 Bit breit sind?

Codezeiger sind eben nicht 64bit, sondern werden nur auf 64bit sign-extended. Damit wird afaik der Code bzw. die Elf-Datei etwas kleiner.

Und nochwas: Wenn ich zur Laufzeit manche Daten nach weit oben mappe (48 Bit virtuelle Addressen sollte man schließlich ausnutzen ), funktioniert das?

Das ist kein Problem. Es bezieht sich bei Daten ja nur auf die Relocations/Symbole in der Elf-Datei, nicht auf die Zeigergröße.

[Krox]

Aha, also ist es praktisch eine Beschränkung des elf formats? Oder anders gesagt, gibt es ein Objekt-Format mit richtigen 64bit Relocations?

Achja, das Problem an sich lässt sich so lösen:

Code: [Auswählen]

mov rax, KernelMain
call raxBei solchen Relocs, wo ld nicht weiß, dass es ein Funktions-Pointer ist, funktioniert es 

[bluecode]

Aha, also ist es praktisch eine Beschränkung des elf formats? Oder anders gesagt, gibt es ein Objekt-Format mit richtigen 64bit Relocations?

Nein, elf könnte es (wenn man dann auch den richtigen relocation typ bekommt von seitens des Compilers). Gcc wird dir auch Code generieren, der ungefähr so ausschaut:

Code: [Auswählen]

mov eax, KernelMain
call rax
D.h. der Compiler nimmt dann auch wirklich an, dass es nur 31bit Addressen sind und lässt die auf 64bit sign-extenden. Es ist aber schon ne Weile her, dass ich mir den von gcc generierten Code angeschaut habe...

[Krox]

schade schade... hab grade schon in den gcc manuals nach nem compiler-switch gesucht, aber --long-calls gibt nur für Mips oder so... nix für normale x86-64er... nagut, dann organisier ich meinen Speicher mal nen bissl um, dann wird das wohl. Danke für die Hilfe

[bluecode]

hab grade schon in den gcc manuals nach nem compiler-switch gesucht, [...]

Die oben genannten switch sind dafür da (-mcmodel=bla).

Was mir gerade einfällt: Wenn du es richtig erklärt nachlesen willst, dann schau in der x64 ABI nach: Link (Kapitel 3.5.1 Architectural Constraints)