[Bug binutils/27666] New: ar doesn't create indices on Solaris/sparcv9
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 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.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.37 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #7 from Nick Clifton --- (In reply to Kinsey Moore from comment #6) > I've tested the new patch and, while everything now compiles and links, > there seems to be some weird behavior with global symbols. Yeah - this is the kind of thing that I was worried about. > This bug was > previously affecting two tests in RTEMS under AArch64 and both tests now > exhibit global symbols not yielding their assigned values. The remainder of > the tests still pass appropriately. Am I correct in thinking that these assigned values are non-zero ? One effect of removing the relocations entirely is that the effected symbol's value is always treated as 0... Do you have a test case that I can look at to see if I can improve the patch ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #8 from Kinsey Moore --- (In reply to Nick Clifton from comment #7) > (In reply to Kinsey Moore from comment #6) > > I've tested the new patch and, while everything now compiles and links, > > there seems to be some weird behavior with global symbols. > > Yeah - this is the kind of thing that I was worried about. > > > This bug was > > previously affecting two tests in RTEMS under AArch64 and both tests now > > exhibit global symbols not yielding their assigned values. The remainder of > > the tests still pass appropriately. > > Am I correct in thinking that these assigned values are non-zero ? You are correct, the assigned values are non-zero in both cases. > One effect of removing the relocations entirely is that the effected > symbol's value is always treated as 0... > > Do you have a test case that I can look at to see if I can improve the > patch ? I'll see if I can come up with a reduced test case. Do you prefer an executable output that runs on QEMU or just something that compiles to an object file to pick apart? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #9 from Nick Clifton --- (In reply to Kinsey Moore from comment #8) > I'll see if I can come up with a reduced test case. Do you prefer an > executable output that runs on QEMU or just something that compiles to an > object file to pick apart? Preferably an assembler source file. Then I can check that the object file either contains the necessary relocations, or else that the correct values have been stored in the constant part of the relevant instructions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #10 from Joel Sherrill --- Nick. Go back to the first comment when I posted this. I put the C code along with assembly from two different optimization levels. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #11 from Nick Clifton --- (In reply to Joel Sherrill from comment #10) > Nick. Go back to the first comment when I posted this. I put the C code > along with assembly from two different optimization levels. Ah - and change the ".set bar,0" to something else, like ".set bar,1". Right ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 --- Comment #12 from Kinsey Moore --- (In reply to Nick Clifton from comment #11) > Ah - and change the ".set bar,0" to something else, like ".set bar,1". > Right ? >From the two tests, one was 0x2800 and one was 0xabc, but I think 1 there should suffice just as well. -- You are receiving this mail because: You are on the CC list for the bug.
