GDB 8.2 Released, Kernel 4.19 Officially the Next LTS Series, Cloudera Launches Open-Source IoT Architecture and Purism's Librem 5 Production Update

2 weeks 5 days ago

News briefs September 5, 2018.

GDB 8.2 has been released. This new version of the GNU Debugger includes support for RiscV ELF, various Python and Aarch64/Linux enhancements, improved flexibility for loading symbol files and more. For more details on all the changes, visit here, and you can download it from the ftp site:

Greg Kroah-Hartman confirmed that the Linux 4.19 kernel will officially be the next LTS series, Softpedia News reports. The 4.19 kernel will be an end-of-year release, likely out in mid-to-late October of this year.

Cloudera has launched an open-source, IoT architecture in collaboration with Red Hat and Eurotech. According to the press release, this end-to-end architecture is "based on open standards and is integrated, flexible and runs on multi- or hybrid-cloud environments", and it's "designed to provide the foundational components that organizations need to quickly and securely roll out IoT use cases".

Purism announces an update to the production and shipping schedule for the Librem 5, "the world's first ethical, user-controlled smartphone". Shipping is now planned for April 2019, due to two silicon bugs that were discovered in the Librem 5's CPU, which is manufactured by NXP. The phones are pre-selling for $599 and run Purism's Free Software Foundation-endorsed PureOS.

News GDB kernel IOT Purism Librem 5 Phone
Jill Franklin

Bug Hunting Inlined Code

2 weeks 5 days ago
by Zack Brown

The Linux kernel has various debugging tools. One is the kernel function tracer, which traces function calls, looking for bad memory allocations and other problems.

Changbin Du from Intel recently posted some code to increase the range of the function tracer by increasing the number of function calls that were actually compiled into the kernel. Not all function calls are ever actually compiled—some are "inlined", a C feature that allows the function code to be copied to the location that calls it, thus letting it run faster. The downside is that the compiled binary grows by the number of copies of that function it has to store.

But, not all inlined functions are specifically intended by the developers. The GNU C Compiler (GCC) also will use its own algorithms to decide to inline a wide array of functions. Whenever it does this in the Linux kernel, the function tracer has nothing to trace.

Changbin's code still would allow functions to be inlined, but only if they explicitly used the inline keyword of the C language. All other inlining done by GCC itself would be prevented. This would produce less efficient code, so Changbin's code never would be used in production kernel builds. But on the other hand, it would produce code that could be far more thoroughly examined by the function tracer, so Changbin's code would be quite useful for kernel developers.

As soon as he posted the patches, bug reports popped up all over the kernel in functions that GCC had been silently inlining. As a result, absolutely nobody had any objections to this particular patch.

There were, however, some odd false positives produced by the function tracer, claiming that it had found bugs that didn't actually exist. This gave a few kernel developers a slight pause, and they briefly debated how to eliminate those false positives, until they realized it didn't really matter. They reasoned that the false positives probably indicated a problem with GCC, so the GCC people would want to be able to see those false positives rather than have them hidden away behind workarounds.

That particular question—what is a kernel issue versus a GCC issue—is potentially explosive. It didn't lead anywhere this time, but in the past, it has led to bitter warfare between the kernel people and the GCC people. One such war was over GCC's failure to support Pentium processors and led to a group of developers forking GCC development into a competing project, called egcs. The fork was very successful, and it began to be used in mainstream Linux distributions instead of GCC. Ultimately, the conflict between the two branches was resolved only after the egcs code was merged into the GCC main branch, and future GCC development was handed over to the egcs team of developers in 1999.

Go to Full Article
Zack Brown