Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 595148

Summary: sys-devel/binutils-2.27 sys-libs/binutils-libs-2.27 version bump
Product: Gentoo Linux Reporter: Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: RESOLVED FIXED    
Severity: normal CC: slyfox, ua_gentoo_bugzilla
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://sourceware.org/ml/binutils/2016-08/msg00237.html
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 591516    
Bug Blocks:    

Description Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-09-26 06:40:11 UTC
I am already successfully using binutils{,-libs}-2.27 on several ~amd64/~x86 systems. Please bump.


Changes in binutils:

* Add a configure option, --enable-64-bit-archive, to force use of a
  64-bit format when creating an archive symbol index.

* Add --elf-stt-common= option to objcopy for ELF targets to control
  whether to convert common symbols to the STT_COMMON type.


Changes in gas:

* Default to --enable-compressed-debug-sections=gas for Linux/x86 targets.

* Add --no-pad-sections to stop the assembler from padding the end of output
  sections up to their alignment boundary.

* Support for the ARMv8-M architecture has been added to the ARM port.  Support
  for the ARMv8-M Security and DSP Extensions has also been added to the ARM
  port.

* ARC backend accepts .extInstruction, .extCondCode, .extAuxRegister, and
  .extCoreRegister pseudo-ops that allow an user to define custom
  instructions, conditional codes, auxiliary and core registers.

* Add a configure option --enable-elf-stt-common to decide whether ELF
  assembler should generate common symbols with the STT_COMMON type by
  default.  Default to no.

* New command line option --elf-stt-common= for ELF targets to control
  whether to generate common symbols with the STT_COMMON type.

* Add ability to set section flags and types via numeric values for ELF
  based targets.

* Add a configure option --enable-x86-relax-relocations to decide whether
  x86 assembler should generate relax relocations by default.  Default to
  yes, except for x86 Solaris targets older than Solaris 12.

* New command line option -mrelax-relocations= for x86 target to control
  whether to generate relax relocations.

* New command line option -mfence-as-lock-add=yes for x86 target to encode
  lfence, mfence and sfence as "lock addl $0x0, (%[re]sp)".

* Add assembly-time relaxation option for ARC cpus.

* Add --with-cpu=TYPE configure option for ARC gas.  This allows the default
  cpu type to be adjusted at configure time.


Changes in ld:

* Add a configure option --enable-relro to decide whether -z relro should
  be enabled in ELF linker by default.  Default to yes for all Linux
  targets except FRV, HPPA, IA64 and MIPS.

* Support for -z noreloc-overflow in the x86-64 ELF linker to disable
  relocation overflow check.

* Add -z common/-z nocommon options for ELF targets to control whether to
  convert common symbols to the STT_COMMON type during a relocatable link.

* Support for -z nodynamic-undefined-weak in the x86 ELF linker, which
  avoids dynamic relocations against undefined weak symbols in executable.

* The NOCROSSREFSTO command was added to the linker script language.

* Add --no-apply-dynamic-relocs to the AArch64 linker to do not apply link-time
  values for dynamic relocations.
Comment 1 Joshua Kinard gentoo-dev 2016-11-14 04:57:55 UTC
Do we have an experimental ebuild of 2.27 somewhere I can test out?  I am able to trigger a BFD assertion failure on MIPS while building a cross-compiler with gcc-6.2.0-r1.  I want to see if it's still present in 2.27 before opening bugs upstream.
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-11-14 06:45:38 UTC
(In reply to Joshua Kinard from comment #1)
> Do we have an experimental ebuild of 2.27 somewhere I can test out?  I am
> able to trigger a BFD assertion failure on MIPS while building a
> cross-compiler with gcc-6.2.0-r1.  I want to see if it's still present in
> 2.27 before opening bugs upstream.

I have a working package in poly-c overlay. It's named sys-devel/binutils-2.27_pre but the _pre is only to distinct it from a possible binutils-2.27 in portage.
Comment 3 Joshua Kinard gentoo-dev 2016-11-14 13:35:29 UTC
(In reply to Lars Wendler (Polynomial-C) from comment #2)
> (In reply to Joshua Kinard from comment #1)
> > Do we have an experimental ebuild of 2.27 somewhere I can test out?  I am
> > able to trigger a BFD assertion failure on MIPS while building a
> > cross-compiler with gcc-6.2.0-r1.  I want to see if it's still present in
> > 2.27 before opening bugs upstream.
> 
> I have a working package in poly-c overlay. It's named
> sys-devel/binutils-2.27_pre but the _pre is only to distinct it from a
> possible binutils-2.27 in portage.

Yeah, still getting the BFD assertion failure there, too.  Looks like a gcc-6.2.x regression on MIPS, then, since I can get the error with binutils 2.25, 2.26, and now, 2.27, but only on gcc-6.x.

For brevity, it's in the ld call to link glibc's libpthread.so file:
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
/usr/libexec/gcc/mips64-unknown-linux-gnu/ld: BFD (Gentoo 2.27 p1.0) 2.27 assertion fail /ramfs/portage/cross-mips64-unknown-linux-gnu/binutils-2.27_pre-r1/work/binutils-2.27/bfd/elfxx-mips.c:9020
collect2: error: ld returned 1 exit status
make[2]: *** [../Makerules:541: /ramfs/portage/cross-mips64-unknown-linux-gnu/glibc-2.24/work/build-n32-mips64-unknown-linux-gnu-nptl/nptl/libpthread.so] Error 1

There any steps to debugging binutils assertion failures by chance?  I know a few things about gcc, but never had to attack bionutils before.