On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei <b...@broadcom.com> wrote:
> Hi,
> Sorry for coming back to this issue after a while. I am still puzzled
> by this. The following are two test files:
>
> a.c
>
> #include <string.h>
> #include <stdio.h>
> extern int foo(int);
> void bar()
> {
> printf("bar\n");
> }
> extern int src[], dst[];
> int vvvvvv;
> int main()
> {
> int ret;
> vvvvvv = 12;
> ret = foo(20);
> memcpy(dst, src, 100);
> return ret + 3;
> }
>
> b.c
> #include <stdio.h>
> int src[100];
> int dst[100];
> extern int vvvvvv;
> extern void bar();
> int foo(int c)
> {
> printf("Hello world: %d\n", c);
> bar();
> return 1000 + vvvvvv;
> }
>
> I compiled with following steps
> ~/work/install-x86/bin/gcc -flto a.c -O2 -c
> ~/work/install-x86/bin/gcc b.c -O2 -c
> ar cru libb.a b.o
> ~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin -o f
> -fwhole-program -save-temps
>
> Since you both mentioned that resolution file is not used to replace
> externally_visible attribute yet,
> I expect there will be link errors regarding both vvvvvv and bar. Somehow,
> GCC doesn't complain at all.
> However, looking at generated assembly code, GCC produces wrong code for
> calling bar, and vvvvvv is
> linked correctly though.
>
> 0000000000400510 <foo>:
> 400510: 48 83 ec 08 sub $0x8,%rsp
> 400514: 89 fe mov %edi,%esi
> 400516: 31 c0 xor %eax,%eax
> 400518: bf 1c 06 40 00 mov $0x40061c,%edi
> 40051d: e8 56 01 00 00 callq 400678 <pri...@plt>
> 400522: 31 c0 xor %eax,%eax
> 400524: e8 d7 fa bf ff callq 0 <__fini_array_end>
> <-------- should call bar.
> 400529: 8b 05 a1 17 00 00 mov 0x17a1(%rip),%eax #
> 401cd0 <vvvvvv>
> 40052f: 48 83 c4 08 add $0x8,%rsp
> 400533: 05 e8 03 00 00 add $0x3e8,%eax
> 400538: c3 retq
> 400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
>
> Is this a bug? GCC should issue warning/error here. Why is vvvvvv linked
> correctly?
> Shouldn't it be treated as static with -fwhile-program and without
> externally_visible?
bar should be indeed eliminated which is what I see with not
using the linker plugin.
If you use the linker-plugin I see in the .optimized dump that
the were eliminated. But it seems that gold picks them up
from the original objects which seem to be retained somehow.
I guess this is a bug in the linker-plugin.
Richard.
> My trunk is 160104 by the way.
