https://sourceware.org/bugzilla/show_bug.cgi?id=13557
LRN <lrn1986 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lrn1986 at gmail dot com
--- Comment #3 from LRN <lrn1986 at gmail dot com> ---
Created attachment 7564
--> https://sourceware.org/bugzilla/attachment.cgi?id=7564&action=edit
Verbose gcc and ld output
This is still unfixed as of gcc-4.9.0 and binutils-2.24.51.20140427.
I do this (the source files are the same, from attachment 6731):
> gcc --verbose -c -flto -g -O2 foo.c -o foo.o
> gcc-ar -rcsv libfoo.a foo.o
> gcc --verbose -c -flto -g -O2 main.c -o main.o
> gcc --verbose -Wl,--verbose=2,-Map,_map -flto -g -O2 main.o -o main ./libfoo.a
And it can't resolve foo.
I did check, gcc-ar runs ar with the right -plugin=... argument. Substituting
"gcc-ar" for "ar" (or for "ar -plugin=...") does not help.
nm ./libfoo.a correctly identifies its contents as:
> foo.o:
> 00000000 T _foo
This is if i have lto_plugin in /mingw/lib/bfd-plugins; if i don't, nm says
this:
> foo.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 r .gnu.lto_.decls.a5a741ee
> 00000000 r .gnu.lto_.inline.a5a741ee
> 00000000 r .gnu.lto_.jmpfuncs.a5a741ee
> 00000000 r .gnu.lto_.opts
> 00000000 r .gnu.lto_.profile.a5a741ee
> 00000000 r .gnu.lto_.pureconst.a5a741ee
> 00000000 r .gnu.lto_.refs.a5a741ee
> 00000000 r .gnu.lto_.symbol_nodes.a5a741ee
> 00000000 r .gnu.lto_.symtab.a5a741ee
> 00000000 r .gnu.lto_foo.a5a741ee
> 00000000 r .rdata$zzz
> 00000000 t .text
> 00000001 C ___gnu_lto_slim
> 00000001 C ___gnu_lto_v1
(gcc-nm, obviously, works regardless of whether a copy of lto plugin is in
/mingw/lib/bfd-plugins, that's the point of having a wrapper).
The output of the commands listed above is attached.
Note where it says:
> attempt to open ./libfoo.a succeeded
it doesn't say:
> (./libfoo.a)foo.o
after that. My guess is that ld just does not understand the object file format
somehow. When i run exactly the same testcase on my Debian machine (with host
gcc), i do get this:
> attempt to open ./libfoo.a succeeded
> (./libfoo.a)foo.o
and everything works.
Same with the map file (not attached, i'll provide it if requrested):
i686-mingw-w64-ld mentions libfoo once:
> LOAD ./libfoo.a
Whereas on Debian libfoo is mentioned at the beginning, where archive members
included to satisfy reference by file are listed:
> ./libfoo.a(foo.o) main.o (symbol from plugin) (foo)
(and, of course, there's a "LOAD ./libfoo.a" later on as well).
I have debug symbols for binutils and gcc. If you tell me where to look, i may
be able to trace how ld opens archives and reads object files from them.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
