Kai Tietz writes:
> I am currently on to build the gcc target support for x86_64-pc-mingw64.
> While this porting I found a strange register truncation, I do not believe
> it is valid. For the c code:
>
> int foo(char *,...);
> int doo(char *h) { return foo("abc ",h); }
>
> compiled result ->
>
> .file ""
> doo .section .rdata,"dr"
> LC0:
> .ascii "abc \0"
> .text
> .globl _doo
> .def _doo; .scl 2; .type 32; .endef
> _doo:
> LFB2:
> pushq %rbp
> LCFI0:
> movq %rsp, %rbp
> LCFI1:
> subq $16, %rsp
> LCFI2:
> movq %rcx, -8(%rbp)
> movq -8(%rbp), %rdx
> movl $LC0, %ecx
> movl $0, %eax
> call _foo
> ...
>
> It leads to a symbol ref to "abc", which is passed to function foo on
> calling via a 32 bit register. This behaviour seems to be wrong, because
> if the base adress of the code segment gets out-side of 2^32 the
> relocation will be incorrect for sure. May somebody can help if my
> thoughts are wrong or not ...
There's nothing strange about it, it's the default with the small code
model. Here's the doc:
`-mcmodel=small'
Generate code for the small code model: the program and its
symbols must be linked in the lower 2 GB of the address space.
Pointers are 64 bits. Programs can be statically or dynamically
linked. This is the default code model.
`-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.
`-mcmodel=medium'
Generate code for the medium model: The program is linked in the
lower 2 GB of the address space but symbols can be located
anywhere in the address space. Programs can be statically or
dynamically linked, but building of shared libraries are not
supported with the medium model.
`-mcmodel=large'
Generate code for the large model: This model makes no assumptions
about addresses and sizes of sections. Currently GCC does not
implement this model.
Andrew.
