Code: Select all
-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.
I am talking about GAS. There is no equivalent option for GAS because the option changes which instructions are emitted, not how the instructions are encoded.sj95126 wrote:Um, ok, but I was asking about gas, not gcc. I know gcc has -mcmodel.
The effective address is 64 bits, but the offset portion can only be 32 bits. This is a limitation of the x64 architecture, not a limitation of GAS. Most instructions cannot encode an offset with more than 32 bits.sj95126 wrote:And yes, some 64-bit instructions can only take a 32-bit operand, but some, like lea, can take a 64-bit operand, yet gas is forcing this to be truncated to 32-bits. You can even see from the encoding:
Where does the documentation say that it's a Linux-specific hack? It works for any x64 code meant to be linked in the highest 2GiB of address space; the Linux kernel just happens to be the most popular example.bzt wrote:I wouldn't recommend mcmodel=kernel, as that's for Linux hacks specifically.
It's in the OSDev page for X86_64:Octocontrabass wrote:Where does the documentation say that it's a Linux-specific hack? It works for any x64 code meant to be linked in the highest 2GiB of address space; the Linux kernel just happens to be the most popular example.bzt wrote:I wouldn't recommend mcmodel=kernel, as that's for Linux hacks specifically.
Right, ok, duh. Brain fade. Been stuck at home too long. That's why the alternate form movabs, to tell the assembler you want to use the full 64-bit address not 32-bit offset -> 64-bit effective. mov is the only instruction that has a moffs64 operand.Octocontrabass wrote:The effective address is 64 bits, but the offset portion can only be 32 bits. This is a limitation of the x64 architecture, not a limitation of GAS. Most instructions cannot encode an offset with more than 32 bits.
That is FUD! Code models are defined in the ABI, and for one thing, ABI will only change over Linus's dead body, and for two, they are defined without regard for the OS. Code model small (the default) means that all link time addresses are below 2GB. Code model medium means that most link time addresses are below 2GB, but some references to special sections exist that might exceed that limit. Code model large means that any link time address can exceed 2GB. And code model kernel means that all link time addresses are above -2GB. Nothing Linux specific about this, at all. It is just that Linux uses this model, which is documented in the place you indicated.bzt wrote:I wouldn't recommend mcmodel=kernel, as that's for Linux hacks specifically. Might change anytime without any notification...
On a page titled "X86-64", we find architecture-specific information? Surely not!It worth noting that code models are different for architectures,
Again, yes of course the information is specific to x86-64. It is on a page titled "X86-64".That is a hack for the Linux kernel on x86_64. It is not available for other architectures,
You have not understood the issue. The code model switch does not replace a linker script. You still need one. The code model switch makes the compiler output different assembler code, so the assembler will emit different relocation types. Which will then allow your code to be linked at a high address, but you still need a linker script to do that (well, or you use -Ttext, but then you miss out on the other advantages of having a linker script).It is better if you use a proper linker script instead to place your kernel into the negative address range.
Referring to a piece that you yourself wrote is possibly not the most convincing way to reinforce an argument. How about an independent reference on the subject?bzt wrote:There's actually a section devoted to this on the wiki: https://wiki.osdev.org/X86-64#Text_Segment_Types.
From that wiki page: For Assembly, you must use the "movabs" instruction instead of "mov".sj95126 wrote:Um, ok, but I was asking about gas, not gcc. I know gcc has -mcmodel.
How about reading the GNU manual I've linked? I've even quoted the relevant part from the GNU manual!!!iansjack wrote:How about an independent reference on the subject?
Wrong! Code models are based on the instruction encoding and addressing scheme! The mcmodel=small and mcmodel=large uses the same registers to pass arguments to functions (as specified by the ABI)! There are common parts true, and the spec overlaps, sure but they are two things! Why does one specify them as two separate gcc command line options, what do you think?nullplan wrote:That is FUD! Code models are defined in the ABI,
What's your problem with a warning and an example? You most certainly need it, because you don't understand the concept, and you did not know that the same mcmodel covers different memory ranges on different architectures. It's not that AArch64 instruction coding is explained in great details on that page! It just says "It worth noting" that there's a difference. It is also important to mention if a particular gcc option is x86_64 only, and therefore non-portable!nullplan wrote:On a page titled "X86-64", we find architecture-specific information? Surely not!
From the GNU gcc manual: "This model has to be used for Linux kernel code." Which means if and when the Linux kernel code mapping changes, this model will change accordingly without a doubt.kzinti wrote:This is non-sense. It's nothing Linux specific.
It doesn't say it was made for Linux. Linux is just a good example. It is in other compilers like the Intel C compiler. I doubt it was made solely for Linux. My old kernel used -fpic. I didn't ever have issues.GCC documentation wrote:-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.
How often does a kernel change base addresses? Linux is staying at 0xFFFFFFFF80000000 (or wherever it is linked to).OSDev Wiki (by bzt) wrote:It is not available for other architectures, and it might change any time to suit the Linux kernel needs.
Look in the mirror at some point.bzt wrote:But guys, what are you doing? Don't make fools of yourselves! Seriously...
Non sequitur. Anyway, the specific terms with the specific meanings are defined in the ABI. Specifically this document, p. 33f. That document is finalized, any change about it, especially about something as major as the code models, would be a breaking change. And it would not break some backwater architecture only five people in the world are using, it would break the main architecture new Linux installations are deployed on. This would only happen over Linus's dead body, and rightly so.bzt wrote:Wrong! Code models are based on the instruction encoding and addressing scheme!
An irrelevant example (that page is about x86_64, bringing up AArch64 helps nobody), and a warning that is wrong. Wrong information deserves to be expunged. The warning "this may change at any time" in particular just creates fear, uncertainty, and doubt in the stability of the psABI. Which would be fine if it were justified, but it isn't. First came the ABI, then came the Linux implementation of it.bzt wrote:What's your problem with a warning and an example?
Portable? What? We are talking about architecture-specific things, which is why they are on the architecture page. Of course the code models are not portable, but they never are, anyway. (Virtual) memory layout is something that has to be fitted to each architecture separately. I don't think anyone misunderstands that. The option shows up in the GCC manual under "x86 Options", in the section on "Machine-Dependent Options". I don't know how anyone would, in any way, get the impression that those options are portable to other architectures.bzt wrote: It is also important to mention if a particular gcc option is x86_64 only, and therefore non-portable!
You misunderstand that sentence: Just because Linux is using the kernel code model doesn't mean the model exists only for Linux. The model exists, because as a side effect of how x86 instruction encodings work, you can more easily access memory within 2GB from the current address, and placing everything within 2GB from zero ensures this. This encoding has been the same since the mid-80s (since the 386), and nobody is going to change it anytime soon.bzt wrote:From the GNU gcc manual: "This model has to be used for Linux kernel code." Which means if and when the Linux kernel code mapping changes, this model will change accordingly without a doubt.
It absolutely does not mean what you say it means. Your conclusion has no logical connection and is not a consequence of the fact that Linux uses the kernel memory model.bzt wrote:From the GNU gcc manual: "This model has to be used for Linux kernel code." Which means if and when the Linux kernel code mapping changes, this model will change accordingly without a doubt.kzinti wrote:This is non-sense. It's nothing Linux specific.
Sorry to intervene here, but I, too, think it will not change if Linux changes. It's a memory model.kzinti wrote:It absolutely does not mean what you say it means.bzt wrote:From the GNU gcc manual: "This model has to be used for Linux kernel code." Which means if and when the Linux kernel code mapping changes, this model will change accordingly without a doubt.kzinti wrote:This is non-sense. It's nothing Linux specific.
