www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - x64 call instruction E8 00 00 00 00?

reply 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
Jan 05 2012
parent reply 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
Jan 05 2012
next sibling parent "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

Jan 05 2012
prev sibling parent "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)

Runtime relocations only happen for shared libraries and global data.
 use objdump with -r and things should make more sense

Jan 05 2012