Bug 12496 - Linker fails with "could not read symbols: Bad value" message
Summary: Linker fails with "could not read symbols: Bad value" message
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-17 02:28 UTC by Dmitry Gorbachev
Modified: 2012-12-07 20:12 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Testcase (277 bytes, text/plain)
2011-02-17 02:28 UTC, Dmitry Gorbachev
Details
Testcase #2 (318 bytes, text/plain)
2011-02-24 07:23 UTC, Dmitry Gorbachev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Gorbachev 2011-02-17 02:28:35 UTC
Created attachment 5250 [details]
Testcase
Comment 1 H.J. Lu 2011-02-21 18:33:48 UTC
I can't reproduce it with BFD linker in CVS.
Comment 2 Dmitry Gorbachev 2011-02-22 18:06:57 UTC
It happens with BFD linker from lto-mixed branch. I CC'ed you, but forgot to mention it in PR — sorry!
Comment 3 H.J. Lu 2011-02-22 23:59:22 UTC
(In reply to comment #2)
> It happens with BFD linker from lto-mixed branch. I CC'ed you, but forgot to
> mention it in PR — sorry!

I can't reproduce it with lto-mixed branch either.
Comment 4 Dmitry Gorbachev 2011-02-23 06:43:06 UTC
I can reproduce it with recent lto-mixed LD (and GCC 4.5/4.6; for 4.5, add -fuse-linker-plugin to CFLAGS).

I see elf_link_add_archive_symbols() is called twice for libdiv.a:

#0  elf_link_add_archive_symbols (abfd=0x81914a8, info=0x8178ce0)
    at ../../binutils-hjl/bfd/elflink.c:5074
#1  0x080bc6b6 in bfd_elf_link_add_symbols (abfd=0x81914a8, info=0x8178ce0)
    at ../../binutils-hjl/bfd/elflink.c:5135
#2  0x08055d12 in load_symbols (entry=0x8184130, place=0xbfffedf8)
    at ../../binutils-hjl/ld/ldlang.c:2827
#3  0x080566ff in open_input_bfds (s=0x8184130, force=1)
    at ../../binutils-hjl/ld/ldlang.c:3258
#4  0x08056651 in open_input_bfds (s=0x81840fc, force=0)
    at ../../binutils-hjl/ld/ldlang.c:3228
#5  0x0805b551 in lang_process () at ../../binutils-hjl/ld/ldlang.c:6534
#6  0x080609ae in main (argc=31, argv=0xbfffef94)
    at ../../binutils-hjl/ld/ldmain.c:437

and second time:

#0  elf_link_add_archive_symbols (abfd=0x81914a8, info=0x8178ce0)
    at ../../binutils-hjl/bfd/elflink.c:5067
#1  0x080bc6b6 in bfd_elf_link_add_symbols (abfd=0x81914a8, info=0x8178ce0)
    at ../../binutils-hjl/bfd/elflink.c:5135
#2  0x08055d12 in load_symbols (entry=0x8184130, place=0xbfffedf8)
    at ../../binutils-hjl/ld/ldlang.c:2827
#3  0x080566ff in open_input_bfds (s=0x8184130, force=1)
    at ../../binutils-hjl/ld/ldlang.c:3258
#4  0x08056651 in open_input_bfds (s=0x81840fc, force=0)
    at ../../binutils-hjl/ld/ldlang.c:3228
#5  0x0805b551 in lang_process ()
    at ../../binutils-hjl/ld/ldlang.c:6534
#6  0x080609ae in main (argc=31, argv=0xbfffef94)
    at ../../binutils-hjl/ld/ldmain.c:437

This is suspicious:

ldlang.c:3244
/* If we are being called from within a group, and this 
   is an archive which has already been searched, then 
   force it to be researched unless the whole archive 
   has been loaded already.  */

elflink.c:5064
/* Doublecheck that we have not included this object 
   already--it should be impossible, but there may be 
   something wrong with the archive.  */
Comment 5 H.J. Lu 2011-02-23 13:17:31 UTC
(In reply to comment #4)
> I can reproduce it with recent lto-mixed LD (and GCC 4.5/4.6; for 4.5, add
> -fuse-linker-plugin to CFLAGS).
>

I need to add -m32 to reproduce it.
Comment 6 H.J. Lu 2011-02-23 22:30:07 UTC
Fixed by commit 7c3077612093d5937cae7432db161234d3edad0f.
Comment 7 Dmitry Gorbachev 2011-02-24 07:23:14 UTC
Created attachment 5260 [details]
Testcase #2

Fails with ld.hjl and ld.bfd (undefined reference to `__udivdi3'). Works with ld.gold and ld.dk.
Comment 8 H.J. Lu 2011-02-24 14:04:04 UTC
(In reply to comment #7)
> Created attachment 5260 [details]
> Testcase #2
> 
> Fails with ld.hjl and ld.bfd (undefined reference to `__udivdi3'). Works with
> ld.gold and ld.dk.

Can you check which copy of __udivdi3 is used by ld.gold and ld.dk?
Is the LTO one or the normal one?
Comment 9 H.J. Lu 2011-02-24 14:10:49 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Created attachment 5260 [details]
> > Testcase #2
> > 
> > Fails with ld.hjl and ld.bfd (undefined reference to `__udivdi3'). Works with
> > ld.gold and ld.dk.
> 
> Can you check which copy of __udivdi3 is used by ld.gold and ld.dk?
> Is the LTO one or the normal one?

If I do "objcopy --redefine-sym __udivdi3=foobar div.o", gold also
fails. I don't think gold behavior is better than ld.lto. I even
consider it is a gold bug.
Comment 10 Dmitry Gorbachev 2011-02-24 16:27:53 UTC
Yes, ld.gold and ld.dk silently use non-LTO part of div.o; it's a bug. However, I don't think that an undefined reference error is not a bug.

1. The testcase compiles well without -flto or with -fno-use-linker-plugin.
2. Imagine a bare-metal program, such as a kernel. When building it, the standard C library is not used, and compiler-generated calls to memcmp, etc. are resolved within the program itself. To work around the bug, a library with these functions must be compiled without -flto.

Again, an unpleasant thing is that the order of linking with LTO differ from one without LTO, and linkers disagree with each other on this matter.

P.S.: Will ld.hjl be obsoleted by ld.dk? If yes, perhaps fixing it does not worth a trouble...
Comment 11 H.J. Lu 2011-02-24 16:58:43 UTC
(In reply to comment #10)
> Yes, ld.gold and ld.dk silently use non-LTO part of div.o; it's a bug. However,
> I don't think that an undefined reference error is not a bug.
> 
> 1. The testcase compiles well without -flto or with -fno-use-linker-plugin.
> 2. Imagine a bare-metal program, such as a kernel. When building it, the
> standard C library is not used, and compiler-generated calls to memcmp, etc.
> are resolved within the program itself. To work around the bug, a library with
> these functions must be compiled without -flto.

I think it is the correct behavior since the LTO version of
the function isn't used anyway.

> Again, an unpleasant thing is that the order of linking with LTO differ from
> one without LTO, and linkers disagree with each other on this matter.
> 
> P.S.: Will ld.hjl be obsoleted by ld.dk? If yes, perhaps fixing it does not
> worth a trouble...

It depends. ld.dk has the same bug as gold.
Comment 12 Dmitry Gorbachev 2011-02-24 21:03:13 UTC
> I think it is the correct behavior since the LTO version of
> the function isn't used anyway.

Do you mean it's a linker "feature" rather then a bug? That is, if GCC generates a call to some function on the LTO stage, and this function is in an object file which is in a static library, then care should be taken to *not* create that object with -flto.
Comment 13 H.J. Lu 2011-02-24 21:12:43 UTC
(In reply to comment #12)
> > I think it is the correct behavior since the LTO version of
> > the function isn't used anyway.
> 
> Do you mean it's a linker "feature" rather then a bug? That is, if GCC
> generates a call to some function on the LTO stage, and this function is in an
> object file which is in a static library, then care should be taken to *not*
> create that object with -flto.

If a file with IR isn't used during LTO stage, it shouldn't be used
at all.
Comment 14 Dmitry Gorbachev 2011-02-24 23:29:50 UTC
The "could not read symbols" thing is now FIXED, and the "undefined reference" problem (which I still feel is a bug) is WONTFIX, as I understand.

I will file another PR for ld.gold / ld.dk bug.

Thus, closing this bug report.
Comment 15 H.J. Lu 2012-12-07 20:12:28 UTC
Works in 2.23 and tracked by "LTO 15" test.