call instruction question

call instruction question

[horseriver]

hi:

here is the disassembly code , 

 629:   0f 84 0e 01 00 00       je     73d <acpi_ec_add+0x125>
 62f:   68 d0 00 00 00          push   $0xd0
 634:   ff 35 10 00 00 00       pushl  0x10
 63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>
 63f:   89 c3                   mov    %eax,%ebx
 641:   5f                      pop    %edi
 642:   58                      pop    %eax
 643:   b8 f4 ff ff ff          mov    $0xfffffff4,%eax


 look at the code at 63a address :

                   63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>

 e8 is a CALL instruction , but , obviously , 63b is not a subroutin address ,so how does this "call 63b " generate?

 amd what does it do ?



thanks! 

Re: call instruction question

[Ian Lance Taylor]

On Wed, Jan 9, 2013 at 10:19 AM, horseriver <horserivers@gmail.com> wrote:
>
> here is the disassembly code ,
>
>  629:   0f 84 0e 01 00 00       je     73d <acpi_ec_add+0x125>
>  62f:   68 d0 00 00 00          push   $0xd0
>  634:   ff 35 10 00 00 00       pushl  0x10
>  63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>
>  63f:   89 c3                   mov    %eax,%ebx
>  641:   5f                      pop    %edi
>  642:   58                      pop    %eax
>  643:   b8 f4 ff ff ff          mov    $0xfffffff4,%eax
>
>
>  look at the code at 63a address :
>
>                    63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>
>
>  e8 is a CALL instruction , but , obviously , 63b is not a subroutin address ,so how does this "call 63b " generate?
>
>  amd what does it do ?

You are looking at an object file, not an executable.  There is a
relocation associated with that address.  The linker will use the
relocation to fill in the final address when you link the object file
into an executable.

If you are using "objdump -d" to get the above disassembly, use
"objdump -dr" to also see the relocation information.

Ian

Re: call instruction question

[horseriver]

On Wed, Jan 09, 2013 at 10:08:42PM -0800, Ian Lance Taylor wrote:
> On Wed, Jan 9, 2013 at 10:19 AM, horseriver <horserivers@gmail.com> wrote:
> >
> > here is the disassembly code ,
> >
> >  629:   0f 84 0e 01 00 00       je     73d <acpi_ec_add+0x125>
> >  62f:   68 d0 00 00 00          push   $0xd0
> >  634:   ff 35 10 00 00 00       pushl  0x10
> >  63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>
> >  63f:   89 c3                   mov    %eax,%ebx
> >  641:   5f                      pop    %edi
> >  642:   58                      pop    %eax
> >  643:   b8 f4 ff ff ff          mov    $0xfffffff4,%eax
> >
> >
> >  look at the code at 63a address :
> >
> >                    63a:   e8 fc ff ff ff          call   63b <acpi_ec_add+0x23>
> >
> >  e8 is a CALL instruction , but , obviously , 63b is not a subroutin address ,so how does this "call 63b " generate?
> >
> >  amd what does it do ?
> 
> You are looking at an object file, not an executable.  There is a
> relocation associated with that address.  The linker will use the
> relocation to fill in the final address when you link the object file
> into an executable.
> 
> If you are using "objdump -d" to get the above disassembly, use
> "objdump -dr" to also see the relocation information.

Thanks!

I use -dr options ,and this is part of  optput :

 676:	        e8 fc ff ff ff       	call   677 <acpi_ec_add+0x5f>
 	     	             677: R_386_PC32   strcpy
 67b:		68 19 00 00 00       	push   $0x19
 		             67c: R_386_32     .rodata.str1.1
 680:		8d 46 75			lea    0x75(%esi),%eax
 683:		50                   	push   %eax


 I have understanded what you say , here are my new  question :

                1. why use "fc ff ff ff "  in call instruction?

                2. In my .c source file ,I have not used  strcpy function , so why it is disassembly out here ?
                after research , I find this call instruction is corresponding  to this line :

                      	       sprintf(acpi_device_name(device), "%s", ACPI_EC_DEVICE_NAME);
                sprintf is a externel implemented function .

                but why in disassebly code it is strcpy ?

                whether something wrong with relocation data?
               
                                                                             
> 
> Ian

Re: call instruction question

[John Fine]

horseriver wrote:
>                 1. why use "fc ff ff ff "  in call instruction?
>   
The call uses PC relative addressing that at execution time is relative 
to the address of the instruction AFTER the call instruction.
But the relative fixup that the compiler can request from the linker is 
relative to the location being fixed, which is inside the call instruction.
So the final value required is four less than the fixup the linker will 
require, so the compiler has initialized the value to be fixed as minus 
four.

Re: call instruction question

[Ian Lance Taylor]

On Wed, Jan 9, 2013 at 2:14 PM, horseriver <horserivers@gmail.com> wrote:
>
>                 1. why use "fc ff ff ff "  in call instruction?

Answered by John Fine.

>                 2. In my .c source file ,I have not used  strcpy function , so why it is disassembly out here ?
>                 after research , I find this call instruction is corresponding  to this line :
>
>                                sprintf(acpi_device_name(device), "%s", ACPI_EC_DEVICE_NAME);
>                 sprintf is a externel implemented function .
>
>                 but why in disassebly code it is strcpy ?
>
>                 whether something wrong with relocation data?

This is a GCC optimization.  GCC converts
    sprintf(buf, "%s", arg);
into
    strcpy(buf, arg);
because the operations are equivalent and strcpy is more efficient.
By default GCC assumes that it can call any function in the C standard
library.  To turn off this assumption, use the -fno-hosted option that
I already mentioned earlier.

Ian

Re: call instruction question

[horseriver]

On Thu, Jan 10, 2013 at 12:12:26PM -0500, John Fine wrote:
> 
> 
> horseriver wrote:
> >                1. why use "fc ff ff ff "  in call instruction?
> The call uses PC relative addressing that at execution time is
> relative to the address of the instruction AFTER the call
> instruction.
> But the relative fixup that the compiler can request from the linker
> is relative to the location being fixed, which is inside the call
> instruction.
> So the final value required is four less than the fixup the linker
> will require, so the compiler has initialized the value to be fixed
> as minus four.

this means  :
  $PC + 0xfffffffc = $pc-4 

 
> 

Re: call instruction question

[horseriver]

On Thu, Jan 10, 2013 at 10:09:48AM -0800, Ian Lance Taylor wrote:
> On Wed, Jan 9, 2013 at 2:14 PM, horseriver <horserivers@gmail.com> wrote:
> >
> >                 1. why use "fc ff ff ff "  in call instruction?
> 
> Answered by John Fine.
> 
> >                 2. In my .c source file ,I have not used  strcpy function , so why it is disassembly out here ?
> >                 after research , I find this call instruction is corresponding  to this line :
> >
> >                                sprintf(acpi_device_name(device), "%s", ACPI_EC_DEVICE_NAME);
> >                 sprintf is a externel implemented function .
> >
> >                 but why in disassebly code it is strcpy ?
> >
> >                 whether something wrong with relocation data?
> 
> This is a GCC optimization.  GCC converts
>     sprintf(buf, "%s", arg);
> into
>     strcpy(buf, arg);
> because the operations are equivalent and strcpy is more efficient.
> By default GCC assumes that it can call any function in the C standard
> library.
  
   yes! I understand what you mean !

   I should not blame gcc's optimization , but here it has caused an error :
   when linking , ld will look for this strcpy's implemention and fill into this .o 
   file with strcpy's address . In my project , strcpy is implemented in  source code.
   so I linked this .o file with that .o which has implemented strcpy , but ld reported this to me :
                              
                      undefined reference to `strcpy' at this .o file

   I could not understand this . Is there some advice ?



>  To turn off this assumption, use the -fno-hosted option that
> I already mentioned earlier.
> 
> Ian

Re: call instruction question

[Ian Lance Taylor]

On Thu, Jan 10, 2013 at 10:06 AM, horseriver <horserivers@gmail.com> wrote:
>
>    I should not blame gcc's optimization , but here it has caused an error :
>    when linking , ld will look for this strcpy's implemention and fill into this .o
>    file with strcpy's address . In my project , strcpy is implemented in  source code.
>    so I linked this .o file with that .o which has implemented strcpy , but ld reported this to me :
>
>                       undefined reference to `strcpy' at this .o file
>
>    I could not understand this . Is there some advice ?

Use "readelf -s" or "nm" to verify that you really have a function
named strcpy in the .o file you expect it to be in.  When linking, use
-Wl,-y,strcpy to trace when the linker sees the strcpy symbol.

Ian