64bit call

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Sun Feb 24 17:07:36 PST 2008


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.



More information about the Digitalmars-d mailing list