I can't wrap my brain around how the calls in dmd's x64 output code work.
According to http://siyobik.info/main/reference/instruction/CALL it is a
call relative to the next instruction (RIP).

And objdump prints just that.

0000000000000000 <_D4test3fooFZi>:
   0:	48 c7 c0 01 00 00 00 	mov    rax,0x1

0000000000000010 <_Dmain>:
  10:	e8 00 00 00 00     call   15 <_Dmain+0x5>
  15:	31 c0              xor    eax,eax
  17:	c3                 ret

While obj2asm prints:

_D4test3fooFZi:
		mov	RAX,1

_Dmain:
		call	  _D4test3fooFZi@PC32
		xor	EAX,EAX
		ret

On Thu, 05 Jan 2012 19:29:06 +0100, Trass3r wrote:

> I can't wrap my brain around how the calls in dmd's x64 output code work. According to http://siyobik.info/main/reference/instruction/CALL it is a call relative to the next instruction (RIP).

objdump shows the address as 0 because the offsets are calculated at runtime by the linker from the global offset table (R_X86_64_32, R_X86_64_PC32)

use objdump with -r and things should make more sense

Thanks for shedding some light on this.

I wonder though why disassembling "works" in some cases and sometimes not:
>int foo()
>{
>       asm
>       {
>               naked;
>               mov RAX, 1;
>       }
>}
>void main()
>{
>       int i = foo();
>}

yields

>0000000000000000 <_Dmain>:
>  0:	55                   	push   rbp
>  1:	48 8b ec             	mov    rbp,rsp
>  4:	e8 00 00 00 00       	call   9 <_Dmain+0x9>
>			5: R_X86_64_PC32	_D4test3fooFZi-0x4
>  9:	31 c0                	xor    eax,eax
>  b:	5d                   	pop    rbp
>  c:	c3                   	ret

while
>void foo() {}
>void bar() {foo();}

turns into
>0000000000000000 <_D5test23barFZv>:
>  0:	55                   	push   rbp
>  1:	48 8b ec             	mov    rbp,rsp
>  4:	e8 00 00 00 00       	call   9 <_D5test23barFZv+0x9>
>			5: R_X86_64_PC32	_D5test23fooFZv-0x4
>  9:	5d                   	pop    rbp
>  a:	c3                   	ret

On Thu, 05 Jan 2012 19:49:23 +0100, Shahid <govellius@gmail.com> wrote:

> On Thu, 05 Jan 2012 19:29:06 +0100, Trass3r wrote:
>
>> I can't wrap my brain around how the calls in dmd's x64 output code
>> work. According to http://siyobik.info/main/reference/instruction/CALL
>> it is a call relative to the next instruction (RIP).
>
> objdump shows the address as 0 because the offsets are calculated at
> runtime by the linker from the global offset table (R_X86_64_32,
> R_X86_64_PC32)
>
Those are relocated at link time.
Runtime relocations only happen for shared libraries
and global data.
> use objdump with -r and things should make more sense