| Summary: | sys-devel/binutils: BFD assertion failure in bfd/elfxx-mips.c:9020 during mips64 cross-toolchain build w/ gcc-6.2.0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Joshua Kinard <kumba> |
| Component: | Current packages | Assignee: | Gentoo Crossdev team <crossdev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mips, slyfox |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | MIPS | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 627914 | ||
|
Description
Joshua Kinard
2016-11-27 11:36:59 UTC
Around line 9020, we have assertion:
BFD_ASSERT (dynobj != NULL
&& (h->needs_plt
|| h->u.weakdef != NULL
|| (h->def_dynamic
&& h->ref_regular
&& !h->def_regular)));
Can you reproduce the linking failure by manually executing the line
from your log? Can the same files be linked successfully with binutils
compiled from an earlier version of gcc?
(In reply to Felix Janda from comment #1) > Around line 9020, we have assertion: > > BFD_ASSERT (dynobj != NULL > && (h->needs_plt > || h->u.weakdef != NULL > || (h->def_dynamic > && h->ref_regular > && !h->def_regular))); > > Can you reproduce the linking failure by manually executing the line > from your log? Can the same files be linked successfully with binutils > compiled from an earlier version of gcc? I haven't tried manually executing that line yet. Have to put that on the list for later, though I doubt it'll change much. For the other question, yes, gcc-5.4.0 has no problems on binutils-2.25 at least. I think I tried 2.26.1 as well, but there was another, unrelated, issue w/ glibc (vfork aliases) that forced me to back down to 2.25 until glibc-2.24 came out. gcc-6.2.0, however, causes this issue reliably on binutils 2.25 to 2.27, so the fault is likely in gcc itself generating bad code in one of the objects that's triggering the assertion. There's a lot of objects that'd need checking, though, and I know little about debugging binutils. How about newer gcc (6.4)? Last time I looked USE=-pie on gcc helped me to restore cross-building toolchain on mips. Given it's a binutils assertion failure I would suspect a binutils bug to fail to handle PIC/PIE. Gentoo enabled PIE-by-default on gcc-6. (In reply to Andreas K. Hüttel from comment #3) > How about newer gcc (6.4)? I've confirmed it's still affected in gcc-7.2.x. (In reply to Sergei Trofimovich from comment #4) > Last time I looked USE=-pie on gcc helped me to restore cross-building > toolchain on mips. > > Given it's a binutils assertion failure I would suspect a binutils bug to > fail to handle PIC/PIE. Gentoo enabled PIE-by-default on gcc-6. Well, the odd thing is, this failure only happens on crossdev builds on my x86_64 box. Native compiles work fine up to gcc-6.4.0 and binutils-2.29*. So if it is PIE-related, it's specific to something in the logic that only happens in a cross-compile scenario. And so far, at least with glibc. Crossdev can't handle uclibc-ng just yet, so I can't test other libc's at the moment. (In reply to Joshua Kinard from comment #5) > (In reply to Andreas K. Hüttel from comment #3) > > How about newer gcc (6.4)? > > I've confirmed it's still affected in gcc-7.2.x. > > > (In reply to Sergei Trofimovich from comment #4) > > Last time I looked USE=-pie on gcc helped me to restore cross-building > > toolchain on mips. > > > > Given it's a binutils assertion failure I would suspect a binutils bug to > > fail to handle PIC/PIE. Gentoo enabled PIE-by-default on gcc-6. > > Well, the odd thing is, this failure only happens on crossdev builds on my > x86_64 box. Native compiles work fine up to gcc-6.4.0 and binutils-2.29*. > So if it is PIE-related, it's specific to something in the logic that only > happens in a cross-compile scenario. And so far, at least with glibc. > Crossdev can't handle uclibc-ng just yet, so I can't test other libc's at > the moment. There is a few things to keep in mind with crossdev: 1. crossdev generates a package named cross-*/gcc and things like 'package.mask sys-libs/gcc pie' do not apply to it 2. when you emerge 'cross-*/gcc' in system you install it on host's ARCH which means you are using amd64 profile, not mips. Thus yes, it's expected pie is masked on native system but not masked in cross-environment. It's easy to verify by building cross-toolchain with USE=-pie. I personally have the following package.use: /etc/portage/package.use/haskell:cross-mips64-unknown-linux-gnu/ghc -gmp /etc/portage/package.use/cross:cross-*/gcc::crossdev -fortran /etc/portage/package.use/cross:cross-*/gcc::crossdev -sanitize /etc/portage/package.use/cross:cross-*/gcc::crossdev -ssp /etc/portage/package.use/cross:cross-*/gcc::crossdev -vtv because quite a few targets are broken. And it's an upstream issue thus I was not too eager to report gentoo bugs. How are things on today's toolchain? Looks like the following toolchain Just Works: - cross-mips64-unknown-linux-gnu/gcc-7.2.0 - cross-mips64-unknown-linux-gnu/glibc-2.26-r4 - cross-mips64-unknown-linux-gnu/binutils-2.29.1-r1 (In reply to Sergei Trofimovich from comment #7) > How are things on today's toolchain? Looks like the following toolchain Just > Works: > > - cross-mips64-unknown-linux-gnu/gcc-7.2.0 > - cross-mips64-unknown-linux-gnu/glibc-2.26-r4 > - cross-mips64-unknown-linux-gnu/binutils-2.29.1-r1 I'll retest and try disabling PIE to see what happens. Also, when did the -v flag to crossdev get removed? I like seeing the build output. That should be added back, IMHO. (In reply to Joshua Kinard from comment #8) > > Also, when did the -v flag to crossdev get removed? I like seeing the build > output. That should be added back, IMHO. n/m, I see what the "new way" is. (In reply to Joshua Kinard from comment #8) > (In reply to Sergei Trofimovich from comment #7) > > How are things on today's toolchain? Looks like the following toolchain Just > > Works: > > > > - cross-mips64-unknown-linux-gnu/gcc-7.2.0 > > - cross-mips64-unknown-linux-gnu/glibc-2.26-r4 > > - cross-mips64-unknown-linux-gnu/binutils-2.29.1-r1 > > I'll retest and try disabling PIE to see what happens. Looks like it works now! I saw in the git log that crossdev itself has some changes related to handling PIE support now, so that is likely what fixed things. Thanks! |
