Summary: | nios2 binutils assertion fail at elf32-nios2.c:1038 | ||
---|---|---|---|
Product: | binutils | Reporter: | Thomas Petazzoni <thomas.petazzoni> |
Component: | binutils | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | nickc, romain.naour |
Priority: | P2 | ||
Version: | 2.25 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2016-01-19 00:00:00 | |
Attachments: | Fix assertion, reduce number of messages about FDE encoding |
Description
Thomas Petazzoni
2015-12-27 14:51:27 UTC
Hi Thomas, I just tried to reproduce the problem, following the steps that you suggested, and nothing went wrong.... Please could you check that the bug still exists for you. I was running the build on an x86_64 machine running Fedora 23, perhaps that makes a difference ? Cheers Nick (In reply to Nick Clifton from comment #1) > Hi Thomas, > > I just tried to reproduce the problem, following the steps that you > suggested, and nothing went wrong.... Please could you check that the bug > still exists for you. > > I was running the build on an x86_64 machine running Fedora 23, perhaps > that makes a difference ? > > Cheers > Nick Thanks Nick for testing! After reporting this bug, we have marked the gtkmm3 package as not available on nios2, as a temporary workaround. So in fact, your build is not building gtkmm3. Could you instead do: $ git clone git://git.busybox.net/buildroot $ cd buildroot $ git checkout 09649f2a305e0b9d52555c35c24178255aa298df $ cat > .config <<EOF BR2_nios2=y BR2_GCC_VERSION_5_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PACKAGE_GTKMM3=y EOF $ make olddefconfig $ make Thanks a lot! Created attachment 8912 [details]
Fix assertion, reduce number of messages about FDE encoding
Hi Thomas,
Thanks - I can now reproduce the problem.
The assertion failures were due to a thinko - the test was not allowing for negative values. The FDE encoding warnings are correct, but there really are too many of them.
So please try out this patch. It should fix the assertion and reduce the number of warnings about FDE encoding to 10. If this works for you then I will commit it to the mainline sources.
Cheers
Nick
(In reply to Nick Clifton from comment #3) > Created attachment 8912 [details] > Fix assertion, reduce number of messages about FDE encoding > > Hi Thomas, > > Thanks - I can now reproduce the problem. > > The assertion failures were due to a thinko - the test was not allowing > for negative values. The FDE encoding warnings are correct, but there > really are too many of them. > > So please try out this patch. It should fix the assertion and reduce the > number of warnings about FDE encoding to 10. If this works for you then I > will commit it to the mainline sources. > > Cheers > Nick Thanks for the patch! Note that I am not able to do a runtime test as I don't have any NIOS2 platform, so all I can do is a build time test. Regarding the FDE encoding warnings, what do they mean exactly? Hi Thomas, (In reply to Thomas Petazzoni from comment #4) > Regarding the FDE encoding warnings, what do they mean exactly? They mean that the binary search table that is part of the .eh_frame_hdr section cannot be created. This happens because the (compiler generated) debug information for the entries in the .eh_frame section use absolute addresses not PC-relative addresses. That means that at run time those addresses will have to be relocated (to wherever the library is being loaded). Hence it is not safe to create a binary search table in the .eh_frame_hdr section as the addresses are not fixed. In practice the warning is not serious. It just means that exception handling might be slower than it could be, but it should still work. Cheers Nick (In reply to Nick Clifton from comment #5) > (In reply to Thomas Petazzoni from comment #4) > > Regarding the FDE encoding warnings, what do they mean exactly? > > They mean that the binary search table that is part of the .eh_frame_hdr > section cannot be created. This happens because the (compiler generated) > debug information for the entries in the .eh_frame section use absolute > addresses not PC-relative addresses. That means that at run time those > addresses will have to be relocated (to wherever the library is being > loaded). Hence it is not safe to create a binary search table in the > .eh_frame_hdr section as the addresses are not fixed. > > In practice the warning is not serious. It just means that exception > handling might be slower than it could be, but it should still work. Great, thanks a lot for the explanation! I will try your patch soon and report back. Hi Nick, Thomas, Thanks for your patch! I tried it over binutils 2.26 release which is currently broken for nios2 toolchain. First we need to backport [1] to be able to build glibc. Then I applied your patch and build gtkmm3 package. Also the same issue with qt (4.8.7) is fixed [2]. But not for imagemagick package which initially failed with [3] and now fail with: CC magick/magick_libMagickCore_6_Q16_la-pixel.lo /tmp/ccXCSISE.s: Assembler messages: /tmp/ccXCSISE.s:13821: Error: r31 cannot be used with jmp; use ret instead /tmp/ccXCSISE.s:14446: Error: r31 cannot be used with jmp; use ret instead Makefile:8776: recipe for target 'magick/magick_libMagickCore_6_Q16_la-pixel.lo' failed make[3]: *** [magick/magick_libMagickCore_6_Q16_la-pixel.lo] Error 1 I wanted to let you know this issue. It's ok to disable imagemagick for now. Binutils 2.26 is not upstream yet, I pushed a branch in github [4] if you want to try using this config: $ cat > .config <<EOF BR2_nios2=y BR2_COMPILER_PARANOID_UNSAFE_PATH=y BR2_GLIBC_VERSION_2_22=y BR2_BINUTILS_VERSION_2_26_X=y BR2_GCC_VERSION_5_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_PACKAGE_IMAGEMAGICK=y EOF Best regards, Romain [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=a7be2893a6449e64fe6cfcdd8700b0a367a69f19 [2] http://autobuild.buildroot.net/results/59f/59fdd94bfaf4f6fb7367f5b2f0b56e2acdd371c7/build-end.log [3] http://autobuild.buildroot.net/results/0bf/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/build-end.log [4] https://github.com/RomainNaour/buildroot/tree/nios2-binutils The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=83da6e748c8f105f07e17f53aa6b99ed7867ff5f commit 83da6e748c8f105f07e17f53aa6b99ed7867ff5f Author: Nick Clifton <nickc@redhat.com> Date: Wed Feb 10 11:25:59 2016 +0000 Correct assertion in NIOS2 linker to allow signed 16-buit immediate values. PR 19405 * elf32-nios2.c (nios2_elf32_install_imm16): Allow for signed immediate values. * elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Limit the number of messages about FDE encoding preventing .eh_frame_hdr generation. Hi Romain. Hi Thomas.
OK - I have applied the patch and I am closing this PR.
This:
> /tmp/ccXCSISE.s:13821: Error: r31 cannot be used with jmp; use ret instead
> /tmp/ccXCSISE.s:14446: Error: r31 cannot be used with jmp; use ret instead
is a seperate bug, and very likely a gcc bug rather than a binutils one. (Assuming that gas is correct in saying that r31 cannot be used with jmp).
Please could you file a new, gcc, bug report, preferably with the source file and gcc command line that triggers the problem, so that it can be investigated.
Cheers
Nick
|