* call instruction question
@ 2013-01-10 6:08 horseriver
2013-01-10 7:56 ` Ian Lance Taylor
0 siblings, 1 reply; 8+ messages in thread
From: horseriver @ 2013-01-10 6:08 UTC (permalink / raw)
To: gcc-help
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 6:08 call instruction question horseriver
@ 2013-01-10 7:56 ` Ian Lance Taylor
2013-01-10 10:12 ` horseriver
0 siblings, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2013-01-10 7:56 UTC (permalink / raw)
To: horseriver; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 7:56 ` Ian Lance Taylor
@ 2013-01-10 10:12 ` horseriver
2013-01-10 18:10 ` John Fine
2013-01-10 18:32 ` Ian Lance Taylor
0 siblings, 2 replies; 8+ messages in thread
From: horseriver @ 2013-01-10 10:12 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 10:12 ` horseriver
@ 2013-01-10 18:10 ` John Fine
2013-01-11 3:48 ` horseriver
2013-01-10 18:32 ` Ian Lance Taylor
1 sibling, 1 reply; 8+ messages in thread
From: John Fine @ 2013-01-10 18:10 UTC (permalink / raw)
To: horseriver; +Cc: Ian Lance Taylor, gcc-help
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 10:12 ` horseriver
2013-01-10 18:10 ` John Fine
@ 2013-01-10 18:32 ` Ian Lance Taylor
2013-01-11 5:17 ` horseriver
1 sibling, 1 reply; 8+ messages in thread
From: Ian Lance Taylor @ 2013-01-10 18:32 UTC (permalink / raw)
To: horseriver; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 18:10 ` John Fine
@ 2013-01-11 3:48 ` horseriver
0 siblings, 0 replies; 8+ messages in thread
From: horseriver @ 2013-01-11 3:48 UTC (permalink / raw)
To: John Fine; +Cc: gcc-help
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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-10 18:32 ` Ian Lance Taylor
@ 2013-01-11 5:17 ` horseriver
2013-01-11 12:32 ` Ian Lance Taylor
0 siblings, 1 reply; 8+ messages in thread
From: horseriver @ 2013-01-11 5:17 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: call instruction question
2013-01-11 5:17 ` horseriver
@ 2013-01-11 12:32 ` Ian Lance Taylor
0 siblings, 0 replies; 8+ messages in thread
From: Ian Lance Taylor @ 2013-01-11 12:32 UTC (permalink / raw)
To: horseriver; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-01-11 5:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-10 6:08 call instruction question horseriver
2013-01-10 7:56 ` Ian Lance Taylor
2013-01-10 10:12 ` horseriver
2013-01-10 18:10 ` John Fine
2013-01-11 3:48 ` horseriver
2013-01-10 18:32 ` Ian Lance Taylor
2013-01-11 5:17 ` horseriver
2013-01-11 12:32 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).