Hi,

Currently I'm writing my own 64Bit Kernel with gdc, but ld gives an error whenever I try to link it somewhere above 2GiB in virtual memory: relocation truncated to fit: R_X86_64_32S

Now my question: why does gdc put 32Bit calls into 64 bit code, and how can I change that behaviour?

Simon B�������������������� wrote:
> Hi,
> 
> Currently I'm writing my own 64Bit Kernel with gdc, but ld gives an error
> whenever I try to link it somewhere above 2GiB in virtual memory:
> relocation truncated to fit: R_X86_64_32S
> 
> Now my question: why does gdc put 32Bit calls into 64 bit code, and how can I
> change that behaviour?

The reason it does that is because it's more efficient and most apps don't need more than the lower 2 GiB for code and static data.
The way to change it is to pass -mcmodel=<model>, where
* <model> == small for "code, static data & symbols in 0-2Gib"
* <model> == medium for "code & static data in lower 2Gib, symbols anywhere"
* <model> == large for "no assumptions about memory layout" (Currently not implemented)
* <model> == kernel. This is the one you probably want to use, as it's the only one that's both implemented and allows your stuff to be outside 0-2Gib. There are still restrictions; all code and static data must be in 2 GiB, but they're in -2GiB to 0 (or depending on what you think the signedness of pointers is[1], the upper 2 GiB of the address space)

Reference: The end of <http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html> (ignore the version number; large is still unimplemented on my 4.1.3-based GDC)


[1]: On the x86_64 the address space is only contiguous if addresses are viewed as signed; if you consider them unsigned there's a huge hole in the middle.