Hi Developers, when trying to build a uclibc based toolchain for cris architecture I get following assertion fail error: BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732 I am using linux 3.9.11, gcc 4.7.3 and uclibc 0.9.33.2. The full gcc command with -v added is here: http://openadk.org/cris-binutils.log Any idea what goes wrong here? thx Waldemar
Still an issue with gcc 6.3.0 and binutils 2.28. Targeting crisv10. Just the line number changed: /home/wbx/embedded-test/openadk/toolchain_generic-cris_uclibc-ng_crisv10/usr/lib/gcc/cris-openadk-linux-uclibc/6.3.0/../../../../cris-openadk-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.28 assertion fail elf32-cris.c:2719 Can be reproduced with: git clone git://openadk.org/git/openadk crisv10 cd crisv10 make ADK_APPLIANCE=new ADK_TARGET_ARCH=cris ADK_TARGET_CPU=crisv10 defconfig make v It does not happen when targeting crisv32. Is the assertion to strict/wrong for crisv10? /* A GOTPLT reloc, when activated, is supposed to be included into the PLT refcount. */ BFD_ASSERT (h->gotplt_refcount == 0 || h->gotplt_refcount <= h->root.plt.refcount);
Here is the build log from the toolchain, all libs involved in the final link and the last command output with -Wl,-M. https://debug.openadk.org/crisv10/ It happens when the final libc.so is created.
(In reply to wbx from comment #2) > Here is the build log from the toolchain, all libs involved in the final > link and the last command output with -Wl,-M. > > https://debug.openadk.org/crisv10/ > > It happens when the final libc.so is created. Thanks for the report. Some information is missing though. Please also attach here the *linker* invocation line (to avoid incorrect guessing from the *gcc* command line in make.log). To find it: Add "-v" to the gcc command line and you'll find it in the stderr output on the last line confusingly called (not "ld" but) "collect2". (To the peanut gallery: I know, but this is the short version for someone to whom all this is new.) From the map output at the link above (see the LOAD lines) and from the gcc command line, I'm missing at least the files libc_so.a libc.map in order to proceed.
(In reply to wbx from comment #1) > Is the assertion to strict/wrong for crisv10? The short answer is "no". The longer answer includes "Other things happen for CRIS v10 than for CRIS v32 for architectural reasons, like PLTGOT to GOT optimization."
Missing files and log added. For the ld verbose output: https://debug.openadk.org/crisv10/gcc-v.log Thanks.
Created attachment 9893 [details] interp.os
Created attachment 9894 [details] ld-uClibc.so.1
Created attachment 9895 [details] libc.map
Created attachment 9896 [details] libc_so.a
Created attachment 9897 [details] libgcc.a
Created attachment 9898 [details] libpthread_nonshared.a
Created attachment 9899 [details] uclibc_nonshared.a Reports should not rely on the contents of external sites, so I've extracted the relevant test-case information. Assuming these files were correctly uploaded despite the attachment-types mishap, they're the preferred means to repeat the bug together with the command-line parameters (to e.g. ld-new): --eh-frame-hdr -mcrislinux -shared -o libuClibc-1.0.22.so -mcrislinux --warn-common --warn-once -z combreloc -O2 -z defs -O1 --version-script libc.map -init __uClibc_init -soname=libc.so.1 --whole-archive libc_so.a --no-whole-archive interp.os ld-uClibc.so.1 uclibc_nonshared.a libpthread_nonshared.a libgcc.a And yes, I could have tarred them together.
Repeated, thanks. Fix forthcoming.
The master branch has been updated by Hans-Peter Nilsson <hp@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=086554e8e6b222518f12acab34e6cc7b5af7fde7 commit 086554e8e6b222518f12acab34e6cc7b5af7fde7 Author: Hans-Peter Nilsson <hp@bitrange.com> Date: Tue Mar 28 23:43:09 2017 +0200 Fix for PR ld/16044: elf32-cris.c h->plt.refcount inconsistency
A link to the commit is available above and the reporter CC:ed on the message to the mailing list. Reporter, while I have no doubt that the issue s fully fixed, I await your confirmation before closing the issue. Observation: readelf says the DSO after the patch is identical to that of just deleting the annoying assert. :) The test-case I added is not known to make a difference in that regard; I just followed the observations from following the original case.
works great. Thanks. Might be a candidate for 2.28 stable branch :)
(In reply to wbx from comment #16) > works great. Thanks. Great. Thanks again for your patience. > Might be a candidate for 2.28 stable branch :) Agreed and that request was indeed made in the message to the mailing list, with CC to the release manager, whose acceptance I believe is required post-release.
The binutils-2_28-branch branch has been updated by Hans-Peter Nilsson <hp@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f85ae672d555af5543bcda6dce71ff6d7e687b50 commit f85ae672d555af5543bcda6dce71ff6d7e687b50 Author: Hans-Peter Nilsson <hp@bitrange.com> Date: Wed Apr 19 15:27:31 2017 +0200 Fix for PR ld/16044: elf32-cris.c h->plt.refcount inconsistency Backport (cherry-pick) from master.