Fall 2017 GNU Toolchain Update
The GNU Toolchain is a collection of programming tools produced by the GNU Project. The tools are often packaged together due to their common use for developing software applications, operating systems, and low-level software for embedded systems.
This blog is part of a regular series covering the latest changes and improvements in the components that make up this Toolchain. Apart from the announcement of new releases, however, the features described here are at the bleeding edge of software development in the tools. This does mean that it may be a while before they make it into production releases, and they might not be fully functional yet. But anyone who is interested in experimenting with them can build their own copy of the Toolchain and then try them out.
Version 2.26 is now out. There are loads of new features and bug fixes in this release. Some of the highlights include:
- A per-thread cache has been added to malloc. Access to the cache requires no locks and therefore significantly accelerates the fast path to allocate and free small amounts of memory. Refilling an empty cache requires locking the underlying arena. Performance
measurements show significant gains in a variety of user workloads. Workloads were captured using a specially instrumented malloc and analyzed with a malloc simulator.
- Unicode 10.0.0 Support.
- The tunables feature is now enabled by default. This allows users to tweak the behavior of the GNU C Library using the GLIBC_TUNABLES environment variable.
- New function reallocarray, which resizes an allocated block (like realloc) to the product of two sizes, with a guaranteed clean failure upon integer overflow in the multiplication.
For the full announcement see: https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
GCC is currently in stage 1 and open with all kinds of exciting new features. Here are some that have made it in already:
Enables support for the next revision of the ISO C++ standard, tentatively planned for 2020. Support is highly experimental, and will almost certainly be in incompatible ways in future releases.
Warn about functions that might be candidates for the (cold) attribute. This is based on static detection and generally will only warn about functions which always leads to a call to another cold function such as wrappers of C++ throw or fatal error reporting functions leading to abort.
Warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a “char *” is cast to an “int *” regardless of the target machine.
Generate code to prevent stack clash style attacks. When this option is enabled, the compiler will only allocate one page of stack space at a time and each page is accessed immediately after allocation. Thus, it prevents allocations from jumping over any stack guard page provided by the operating system.
Most targets do not fully support stack clash protection. However, on those targets, the option will protect dynamic stack allocations. The option may also provide limited protection for static stack allocations if the target supports the -fstack-check=specific option.
This option enables instrumentation of pointer arithmetic. If the pointer arithmetic overflows, a run-time error is issued.
This option enables instrumentation of arguments to selected built-in functions. If an invalid value is passed to such arguments, a run-time error is issued. E.g. passing 0 as the argument to __builtin_ctz or __builtin_clz invokes undefined behavior and is diagnosed by this option.
Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function calls, function returns, and indirect jump) are valid. This prevents diverting the flow of control to an unexpected target. This is intended to protect against such threats as Return-oriented Programming (ROP), and similarly call/jmp-oriented programming (COP/JOP).
Generate <N> NOPs right at the beginning of each function, with the function entry point before the <M>th NOP. If <M> is omitted, it defaults to 0 so the function entry points to the address just at the first NOP.
The NOP instructions reserve extra space, which can be used to patch in any desired instrumentation at runtime if the code segment is writeable.
For run-time identification, the starting addresses of these areas, which correspond to their respective function entries minus <M>, are additionally collected in the __patchable_function_entries section of the resulting binary.
Produce a static position independent executable on targets that support it. A static position independent executable is similar to a static executable but can be loaded at any address without a dynamic linker. For predictable results, you must specify the same set of options used for compilation (-fpie, -fPIE, or model suboptions) when you specify this linker option.
There is also a new variable attribute:
This specifies that an object or member declaration with type array of “char” or pointer to “char” is intended to store character arrays that do not necessarily contain a terminating NUL character. This is useful to avoid warnings when such an array or pointer is used as an argument to a bounded string manipulation function such as strncpy. For example without the attribute this code:struct Data
char name  __attribute__ ((nonstring));
void f (struct Data * pd, const char * s)
strncpy (pd->name, s, sizeof pd->name);
} would produce a warning about the call to strncpy not producing a terminated string.
Version 2.29.1 has been released. This is just a point release over the original 2.29 release, but it does include some important bug fixes, especially for x86_64 and PowerPC.
In the development sources, support for the command line option “-z globalaudit” has been added. This forces audit library to be run for every dynamic object loaded by an executable – if the loader supports this functionality.
Also, the EXCLUDE_FILE linker script directive can now be placed within any of the SORT_* directives, to partition files out of the sort.
The x86_64 assembler adds support for the GFNI, VAES, VPCLMULQDQ, AVX512_VBMI2, AVX512_VNNI, AVX512_BITALG, NOAVX512_VBMI2, NOAVX512_VNNI, and NOAVX512_BITALG extensions to the instruction set.
The PowerPC assembler now has support for the Freescale SPE2 instructions.
- GDB now supports access to the guarded-storage-control registers and the software-based guarded-storage broadcast control registers on IBM z14.* On Unix systems, GDB now supports transmitting environment variables that are to be set or unset to GDBserver. These variables will affect the environment to be passed to the remote inferior.
- GDB no longer assumes functions with no debug information return ‘int’.
This means that GDB now refuses to call such functions unless you tell it the function’s type, by either casting the call to the declared return type, or by casting the function to a function pointer of the right type, and calling that:(gdb) p getenv (“PATH”)
‘getenv’ has unknown return type; cast the call to its declared return type
(gdb) p (char *) getenv (“PATH”)
$1 = 0x7fffffffe “/usr/local/bin:/”…Similarly, GDB no longer assumes that global variables with no debug info have type ‘int’, and refuses to print the variable’s value unless you tell it the variable’s type:(gdb) p var
‘var’ has unknown type; cast it to its declared type
(gdb) p (float) var
$3 = 3.14
- Support for ARM and AArch64 on FreeBSD has been added.
Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.
Take advantage of your Red Hat Developers membership and download RHEL today at no cost.