views:

41

answers:

1

Hi all,

I had just a look at a very simple SPARC assembly output that I got from this C programm:

int addition_func(int a, int b)
{
  return(a+b);
}

void main()
{

int a = 20;
int b = 19;
int res;    

res = addition_func(a, b);
}

Disassembly of section .text:

00000000 <addition_func>:
 0: 81 c3 e0 08     retl 
 4: 90 02 00 09     add  %o0, %o1, %o0

00000008 <main>:
 8: 90 10 20 14     mov  0x14, %o0
 c: 92 10 20 13     mov  0x13, %o1
10: 82 13 c0 00     mov  %o7, %g1
14: 40 00 00 00     call  14 <main+0xc>
18: 9e 10 40 00     mov  %g1, %o7
1c: 01 00 00 00     nop 

I do not understand why the "call" instruction says:

  call  14 <main+0xc>

Why is it not:

  call  0 <addition_func+0x0>

The program works fine, however, this output does not make too much sense to me. Any suggestions why it is handled this way?

Thanks

+2  A: 

I'll assume you're using GCC, but other compilers/assemblers should have equivalent options.

That's not the assembly output; it's the disassembly. If you want the input to the assembler, use gcc -S.

The notable number is not 14 — the instruction is a call to a relative address of 0:

14: 40 00 00 00     call  14 <main+0xc>

If you're disassembling an object file compiled with -ffunction-sections, then the instruction is simply a placeholder to be fixed up by the linker. The linker will fill it in with the actual offset to addition_func; you might see this if you dump the relocation tables.

tc.
Alright, so the linker fixes this address problem. I will have a further look into this issue, it not completely clear why it looks as it looks
Markus
It's not a problem; it's by design.
tc.