Bug 12562 - Ld.dk fails with "could not read symbols: Bad value" message
Summary: Ld.dk fails with "could not read symbols: Bad value" message
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: Dave Korn
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-10 11:12 UTC by Dmitry Gorbachev
Modified: 2016-11-24 20:45 UTC (History)
1 user (show)

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


Attachments
Testcase (219 bytes, text/plain)
2011-03-10 11:12 UTC, Dmitry Gorbachev
Details
Fix typo in 003ld-plugin-api-link-order.diff (414 bytes, patch)
2011-03-12 03:05 UTC, Dave Korn
Details | Diff
Fixed respin. (673 bytes, patch)
2011-03-12 05:58 UTC, Dave Korn
Details | Diff
Testcase #2 (254 bytes, text/plain)
2011-03-12 16:00 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-03-10 11:12:42 UTC
Created attachment 5284 [details]
Testcase

elf_link_add_archive_symbols() is called twice for libxxx.a:

#0  elf_link_add_archive_symbols (abfd=0x818c440, info=0x8175cc0)
    at ../../binutils-2.21.51/bfd/elflink.c:5072
#1  0x080ba822 in bfd_elf_link_add_symbols (abfd=0x818c440, info=0x8175cc0)
    at ../../binutils-2.21.51/bfd/elflink.c:5135
#2  0x0805564f in load_symbols (entry=0x8176064, place=0xbfffefc8)
    at ../../binutils-2.21.51/ld/ldlang.c:2808
#3  0x0805603a in open_input_bfds (s=0x8176064, force=1)
    at ../../binutils-2.21.51/ld/ldlang.c:3239
#4  0x08055f8c in open_input_bfds (s=0x8176054, force=0)
    at ../../binutils-2.21.51/ld/ldlang.c:3209
#5  0x0805af03 in lang_process () at ../../binutils-2.21.51/ld/ldlang.c:6538
#6  0x0805ea2c in main (argc=17, argv=0xbffff174)
    at ../../binutils-2.21.51/ld/ldmain.c:461

and second time:

#0  elf_link_add_archive_symbols (abfd=0x818c440, info=0x8175cc0)
    at ../../binutils-2.21.51/bfd/elflink.c:5069
#1  0x080ba822 in bfd_elf_link_add_symbols (abfd=0x818c440, info=0x8175cc0)
    at ../../binutils-2.21.51/bfd/elflink.c:5135
#2  0x0805564f in load_symbols (entry=0x8176064, place=0xbfffefc8)
    at ../../binutils-2.21.51/ld/ldlang.c:2808
#3  0x0805603a in open_input_bfds (s=0x8176064, force=1)
    at ../../binutils-2.21.51/ld/ldlang.c:3239
#4  0x08055f8c in open_input_bfds (s=0x8176054, force=0)
    at ../../binutils-2.21.51/ld/ldlang.c:3209
#5  0x0805af73 in lang_process () at ../../binutils-2.21.51/ld/ldlang.c:6559
#6  0x0805ea2c in main (argc=17, argv=0xbffff174)
    at ../../binutils-2.21.51/ld/ldmain.c:461
Comment 1 Dave Korn 2011-03-10 11:35:34 UTC
make: *** No rule to make target `libxxx.a(toupper.o)', needed by `libxxx.a'.  S
top.

Hmm, what version of make are you using?

Also, are you testing CVS HEAD from before or after the five patches I committed a couple of hours ago?
Comment 2 Dave Korn 2011-03-10 11:39:18 UTC
(In reply to comment #1)
> make: *** No rule to make target `libxxx.a(toupper.o)', needed by `libxxx.a'. 
> Stop.
> 
> Hmm, what version of make are you using?

Disregard that, was caused by a typo when invoking 'patch' to unpack the testcase!
Comment 3 Dmitry Gorbachev 2011-03-11 12:23:30 UTC
> Also, are you testing CVS HEAD from before or after
> the five patches I committed a couple of hours ago?

After, with and without 005ld-link-stage2.diff.
Comment 4 Dave Korn 2011-03-12 03:05:03 UTC
Created attachment 5298 [details]
Fix typo in 003ld-plugin-api-link-order.diff

There was a typo in 003ld-plugin-api-link-order.diff, at the point where it has to open the new files that were added by the plugin through the add_input_file callback; it starts at the wrong point in the chain of input files, reopening the existing ones before it reaches the newly-added files.  Reopening the object files is ignored, but reopening the libraries causes them to be rescanned, and since toupper still isn't defined at this point - the ltrans.o file not having been opened yet - when we reopen libxxx we pull in toupper.o again (it already having been pulled in, then claimed by the plugin, first time round).  The backend complains about the same library module being supposedly pulled in twice.

Solved by starting the reopen at the correct point, i.e. the old tail of the list, which is where the new input files will have been added.
Comment 5 Dave Korn 2011-03-12 05:35:42 UTC
Comment on attachment 5298 [details]
Fix typo in 003ld-plugin-api-link-order.diff

patch is buggy.  will spin a new one tomorrow.
Comment 6 Dave Korn 2011-03-12 05:58:59 UTC
Created attachment 5299 [details]
Fixed respin.

Moved all the chain manipulation inside the if-new-files-added test.  Appears to work properly this time.
Comment 7 Dave Korn 2011-03-12 06:00:55 UTC
(In reply to comment #6)
> Created attachment 5299 [details]
> Fixed respin.
> 
> Moved all the chain manipulation inside the if-new-files-added test.  Appears
> to work properly this time.

I have inadvertently mixed code and variable declarations c99 style there; I'll refactor that before I send it to the mailing list but it should still be good for testing.
Comment 8 Dmitry Gorbachev 2011-03-12 16:00:17 UTC
Created attachment 5302 [details]
Testcase #2

(Is it ok to post here, or should I file another bug report for it?)
Comment 9 Dave Korn 2011-03-12 16:21:34 UTC
(In reply to comment #8)
> Created attachment 5302 [details]
> Testcase #2
> 
> (Is it ok to post here, or should I file another bug report for it?)

Can you check whether that works with GOLD?  If GOLD also fails (though perhaps in a different way - maybe a redefinition error for bar) then I think the first thing would be to post this testcase to the binutils list and try and figure out what is *supposed* to happen.  That foo symbol is invisible to LTO, we might just decide that it's not valid code.  If you replace the asm by

void foo (void) __attribute__ ((alias("bar"))) ;

it all works fine, as we would hope.
Comment 10 Dmitry Gorbachev 2011-03-12 17:38:40 UTC
Both ld.gold and ld.hjl print warnings "cannot find entry symbol 'foo'". Still better then obscure "libfoobar.a: could not read symbols: Bad value" error.
Comment 11 Dave Korn 2011-03-12 17:49:21 UTC
(In reply to comment #10)
> Both ld.gold and ld.hjl print warnings "cannot find entry symbol 'foo'". Still
> better then obscure "libfoobar.a: could not read symbols: Bad value" error.

Right.  I figure I can make ld.bfd do at least that much.  What it needs to be able to do is open a library, pull in an archive member, have it claimed by the plugin, then when the plugin has added ltrans objects and a symbol still isn't satisfied it needs to be allowed to pull the same member in again, this time getting only the native object.  Just need to find the right place to clear the archive_pass flag on archive members that the plugin claims.

There are two separate bugs here; the first is that ld.bfd was reopening the file chain at the wrong point, and this exposed the second: that we don't support pulling in the native version of an archive member if its symbols are still required after the plugin claimed it first time round.  But I can't see much use in opening a second bug just for the sake of the paperwork, let's just call it a bug with two parts :)
Comment 12 Dmitry Gorbachev 2016-11-24 20:45:19 UTC
Old.