• Trass3r (17/17) Jan 05 2012 I can't wrap my brain around how the calls in dmd's x64 output code work...
• Shahid (5/8) Jan 05 2012 objdump shows the address as 0 because the offsets are calculated at
• Trass3r (6/35) Jan 05 2012 Thanks for shedding some light on this.
• Martin Nowak (4/12) Jan 05 2012 Those are relocated at link time.

Trass3r <un known.com> writes:

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

Shahid <govellius gmail.com> writes:

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

"Trass3r" <un known.com> writes:

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

"Martin Nowak" <dawg dawgfoto.de> writes:

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