https://sourceware.org/bugzilla/show_bug.cgi?id=27666
Bug ID: 27666
Summary: ar doesn't create indices on Solaris/sparcv9
Product: binutils
Version: 2.37 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: ro at gcc dot gnu.org
CC: amodra at gmail dot com
Target Milestone: ---
Target: sparcv9-sun-solaris2.*
On binutils master, quite a number of tests currently fail on Solaris/sparcv9.
E.g.
FAIL: ar thin archive
and several more where the Archive index: section is missing from the nm
--print-armap output.
Likewise, several ld tests FAIL like this:
./ld-new: tmpdir/libpr25910.a: error adding symbols: archive has no index; run
ranlib to add one
failed with: <./ld-new: tmpdir/libpr25910.a: error adding symbols: archive has
no index; run ranlib to add one>, no expected output
FAIL: --export-dynamic-symbol foo archive
And indeed, even with an explicit ar rs no index is created. This is not very
easy to diagnose, it seems: I needed to use file to note the common issue of
missing archive index.
Looking back, this has worked in binutils 2.35, but was already broken in 2.36.
Using side-by-side debugging with (working) Solaris/amd64 and (broken)
Solaris/sparcv9, I found that in _bfd_write_archive_contents hasobjects
remains 0 after the bfd_check_format call.
In format.c (bfd_check_format_matches), the second call to
BFD_SEND_FMT (abfd, _bfd_check_format, (abfd))
on l.343 matches only once on amd64 (for x86_64_elf64_sol2_vec), while it
matches twice on sparcv9 (both for sparc_elf64_sol2_vec and sparc_elf64_vec).
That sort of rang a bell and I found that
https://sourceware.org/pipermail/binutils/2021-January/114778.html
commit 3677b7296185e6abfe8327c00c460712151ade15
Author: Alan Modra <amo...@gmail.com>
Date: Wed Jan 6 12:01:10 2021 +1030
sparc-sun-solaris2 and sparc64-sun-solaris2 config
had added the non-_sol2 vectors on Solaris/SPARC. Reverting the config.bfd
part of the patch fixed the archive index issue.
I believe that I had omitted the non-_sol2 vectors for a reason back in 2010:
http://sourceware.org/ml/binutils/2010-10/msg00348.html
There were similar ambiguities IIRC.
On top of that, I believe the failing tests are better fixed differently:
* You've already taken the first step in making the dump files both forms of
the target names, with and without the _sol2 suffix.
* The next step, I believe, would be to pass -m..._sol2 on Solaris (both sparc
and x86).
* The ugliest part is that due to differences in the Solaris ABI, the dumps
differ from the Linux ones. Unfortunately, there's no way to represent
conditional sections in the dumps and keeping separate copies almost
guarantees
that they diverge in the future.
--
You are receiving this mail because:
You are on the CC list for the bug.
