December ’15/January ’16 GNU Toolchain Update

First of all I have an apology to make. I managed to reformat my hard drive over the holidays, wiping away all of my notes for this blog. In particular I was contacted by a reader about an enhancement to gcc’s inline assembler support which I have now totally lost. 🙁 So, dear reader, wherever you are, I apologise, and if you contact me again I will make sure that the extended asm enhancement gets mentioned in the next blog post.

The big news, for me at least, is that binutils 2.26 is now out.  This release contains lots of bug fixes of course, plus a few new features:

  • A new configure option:  –enable-compressed-debug-sections=[all,gas,gold,ld,none]
    This decides whether DWARF debug sections should be compressed by default. For now this option is off for all of the tools, although of course it can be enabled via a command line option.  In future releases of binutils however, the option will be enabled by default.
  • Support for the ARC EM/HS and ARC600/700 architectures.
  • Support for the LLVM plugin.
  • Experimental support for linker garbage collection (–gc-sections) for COFF and PE based targets.
  • A new linker command line option: –orphan-handling=[place|warn|error|discard] is available which adjusts how orphan sections are handled. The default is place which gives the normal behaviour. warn and error issue a warning or error respectively when an orphan section is found, and discard will discard the section entirely.
  • The objcopy tool has a new option insert symbols into a file:  –add-symbol <name>=[<section>:]<value>[,<flags>]  It also has a new option to replace the contents of an existing section with the contents of a specified file:  –update-section <section>=<filename>
  • In the assembler, symbol and label names can now be enclosed in double quotes (“) which allows them to contain characters that are not part of valid symbol names in high level languages.
  • Support for the ARMv8.1 architecture has been added to the AArch64 and ARM ports.
    The next binutils release (2.27) should be happening in July of this year as the project attempts to move to a 6 month release schedule.

In the development binutils there is now support for ARM NOREAD sections. These are executable sections which contain code which the user is not allowed to see.
Next – there is a new release of the Newlib C library. Version 2.3.0 contains several enhancements and improvements, including:

  • Dynamic atexit logic fixed.
  • ARM performance enhancements.
  • New version of strtold.
  • ARC platform support redone.
  • Strftime improvements/enhancements.
  • Complex math enhancements.
  • Visium platform support added.
  • OR1K platform support added.

GCC meanwhile continues working on reducing bug numbers so that a version 6 branch can be created. In practice this means that new features are not being added to the sources at this point, although there is one new warning option to report:  -Winvalid-memory-model

This warns for invocations of __atomic builtins, __sync builtins, and the C11 atomic generic functions with a memory consistency argument that is either invalid for the operation or outside the range of values of the memory_order enumeration. For example, since the __atomic_store and __atomic_store_n builtins are only defined for the relaxed, release, and sequentially consistent memory orders the following code will produce a warning:

void store (int *i)
__atomic_store_n (i, 0, memory_order_consume);

This option is enabled by default.

The development version of GCC also no longer supports DWARF Version 1, which is substantially different than Version 2 and later. For historical reasons, some other DWARF-related options (including -feliminate-dwarf2-dups and -fno-dwarf2-cfi-asm) retain a reference to DWARF Version 2 in their names, but apply to all currently supported versions of DWARF.
The GDB debugger continues to improve as well, and in the last couple of months these new features have been added to the development version:

  • Support for debugging kernel-based threads on FreeBSD.
  • Thread numbers are now per inferior instead of global. If you are debugging multiple inferiors, GDB displays thread IDs using a qualified INF_NUM.THR_NUM form. For example:

(gdb) info threads
Id Target Id Frame
1.1 Thread 0x7ffff7fc2740 (LWP 8155) (running)
1.2 Thread 0x7ffff7fc1700 (LWP 8168) (running)
* 2.1 Thread 0x7ffff7fc2740 (LWP 8157) (running)
2.2 Thread 0x7ffff7fc1700 (LWP 8190) (running)

As consequence, thread numbers as visible in the $_thread convenience variable and in Python’s InferiorThread.num attribute are no longer unique between inferiors.

GDB now maintains a second thread ID per thread, referred to as the global thread ID, which is the new equivalent of thread numbers in previous releases. See also $_gthread below.

For backwards compatibility, MI’s thread IDs always refer to global IDs.

Commands that accept thread IDs now accept the qualified INF_NUM.THR_NUM form as well. For example:

(gdb) thread 2.1
[Switching to thread 2.1 (Thread 0x7ffff7fc2740 (LWP 8157))] (running)

In commands that accept a list of thread IDs, you can now refer to all threads of an inferior using a star wildcard. GDB accepts INF_NUM., to refer to all threads of inferior INF_NUM, and to refer to all threads of the current inferior. For example:
info threads 2.*

You can use “info threads -gid” to display the global thread ID of all threads.

The new convenience variable $_gthread holds the global number of the current thread, and $_inferior holds the number of the current inferior.

  • GDB now displays the ID and name of the thread that hit a breakpoint or received a signal, if your program is multi-threaded. For example:

Thread 3 “bar” hit Breakpoint 1 at 0x40087a: file program.c, line 20.
Thread 1 “main” received signal SIGINT, Interrupt.


That’s all for now. More again in a couple of month’s time.

Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.


What did you think of this article?
-1+1 (No Ratings Yet)

Leave a Reply