www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 64bit call

reply Simon Bürger <krox gmx.net> writes:
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?
Feb 23 2008
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Feb 24 2008