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