GNU Tools Cauldron 2022

THIS PAGE IS AUTO-GENERATED, DO NOT MODIFY BY HAND

* indicates a talk which will be given remotely.

THIS PAGE IS AUTO-GENERATED, DO NOT MODIFY BY HAND

Talks

ABI analysis, libabigail and CTF

Speaker(s): Guillermo E. Martinez Quezada

libabigail is a library and a set of tools to extract, constructing, manipulating, serializing, comparing and de-serializing ABI-relevant artifacts from binary files, providing detailed information about their differences and it helps to build tools to infer interesting conclusions about these differences.

libabigail is able to read ELF, DWARF, & XML files to build an IR of the ABI. New support was added to now be capable to read CTF debug information from ELF binaries including the linux kernel image and linux kernel modules.

The Compact C Type Format (CTF) is a way of representing information about a binary program; it can be seen as a simpler alternative to the widely used DWARF format.

One of the major improvement is the time spent to extract the ABI from binary files using the libabigail CTF reader compared with DWARF reader in libabigail. For example extracting ABI information from the Linux kernel using DWARF reader takes ~3m40s and and using CTF reader takes 0m50s, this is up to ~4.5 time less time

In this talk we will show how we added support for a new reader in libabigail and how the type information is used to derive libabigail's notion of an ABI. Then we will discuss about the concept of ABI, how it is implemented in tools, and hint some ways the toolchain could be leveraged to provide additional useful information to these tools, for instance some gcc attributes modify the ABI but they are not represented in libabigail IR objects and in some cases neither in DWARF/CTF debug information.

Anatomy of ROCgdb (GDB for AMD GPUs)

Speaker(s): Simon Marchi, Pedro Alves, Zoran Zaric, Lancelot Six, Laurent Morichetti, Tony Tye

Slides: Anatomy of ROCgdb.pdf

ROCgdb is a GDB port capable of debugging ROCm applications which offload compute kernel workloads on AMD GPUs. The presentation will provide an overview of the distinctive features of GPU architectures and how they are exposed to the user via the HIP (Heterogeneous Interface for Portability) programming model.

Providing a fluid debugging experience that matches the user's view of the program in this programming model requires major changes in the design of GDB. Some of the key features and design changes of ROCgdb are:

• Presentation of compute kernel threads under the same inferior as host threads.
• Support for SIMT lanes and thread divergence in many GDB commands.

• Support for [extensions to DWARF for Heterogenous Debugging](https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html) allowing compilers to describe complex location descriptions not supported by DWARF 5, and more.

• Support for address spaces, distinct from source level address classes.
• Generalization of the "commit-resumed" concept to avoid unnecessary resumptions.
• Redesign of how Ctrl-C is handled in GDB.

We will discuss some technical details behind these features. Some of them are considered complete, others still contain temporary solutions that need to be taken care of. We will also provide an update about the upstreaming efforts.

CTF Frame format support in the GNU Toolchain

Speaker(s): Indu Bhagat

Slides: Cauldron_2022_ctf_frame.pdf

CTF Frame format compactly represents the minimal necessary unwind information needed for virtual stack unwinding: Canonical Frame Address (CFA), Frame Pointer (FP), and the Return Address (RA). Currently, it supports AMD64 and AAPCS64 ABIs. CTF Frame information is made available to the users via an allocatable, loadable section named .ctf_frame in a segment PT_GNU_CTF_FRAME of its own.

CTF Frame format is designed for those applications which need fast, online stack unwinding. In this talk, we will discuss the specification of the CTF Frame format and implementation of it in the GNU Toolchain. The assembler generates the CTF Frame unwind information using the existing CFI directives. The linker merges the input .ctf_frame sections and places the output .ctf_frame section in a segment of its own. Support has also been added for textual dump of the .ctf_frame section via readelf and objdump.

GCC -fanalyzer update

Speaker(s): David Malcolm

Slides: 2022-Cauldron-analyzer-talk.pdf

In this talk I'll give an update on the status of -fanalyzer, the static analysis option I added to GCC in 2020. I'll talk about:

• serialization of static analysis results (and of other diagnostics),
• my efforts at using -fanalyzer on the Linux kernel,
• what's new in -fanalyzer for GCC 13, and
• possible future directions for the analyzer

GCC Intrinsic & Auto-Vectorization for RISC-V Vector Extension

Speaker(s): Juzhe Zhong (RiVAI Technologies), Xi Wang (RIOS Lab, Tsinghua University), Zhangxi Tan (RiVAI Technologies & RIOS Lab, Tsinghua University)

RISC-V Vector (RVV) is an instruction-set architecture extension that provides RISC-V vectorization support. It enables RISC-V processors to process data arrays, alongside traditional scalar operations in the SIMD manner to enhance the performance via data-level parallelism.

The optimized compiler support is critical to enhance the applicability and portability of RISC-V Vector extension. However, existing RVV implementations in GCC toolchain can not effectively satisfy such need. Therefore, we introduce an open-source RVV GCC design and implementations including the 80K intrinsic and complete auto-vectorization support of int8,int16,int32,int64,fp16,fp32,fp64. Our GCC RVV implementation outperforms the LLVM RVV support by 20% (up to 50%) based on our evaluation results. Our efforts have been included in the RISC-V foundation repository: https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next.

In this presentation, we will cover the following topics:

1. RVV basic concept.
2. RVV intrinsic implementation.
   1. RVV intrinsic builtin framework in GCC.
   2. RVV insert-vsetvli Pass implementation and optimization (In RVV, almost all the instruction needs compiler to insert vsetvli instruction automatically).
3. Auto-vectorization using RVV instruction.
   1. VLA (Vector length agnostic) auto-vectorization.
   2. VLS (Vector length specific) auto-vectorization.
   3. The implementation details of vector loop condition control using RVV vsetvli instruction mechanism.
   4. Add RVV related auto-vectorization standard pattern to optimize auto-vectorization.
4. Introduction of testcases for RVV feature (intrinsic and auto-vectorization). 1 .RVV GCC auto-vectorization performance data of some program project for example: tensorflow-micro (spike instruction count).
5. RVV GCC support status including supported features and TODO features.

GNU poke and the GNU Toolchain

Speaker(s): Jose E. Marchesi, Mohammad-Reza Nabipoor

It's been two years since GNU poke (the extensible editor for structured binary data) was first published during the GNU Tools Cauldron 2019 in Montreal. During this time poke development has progressed very fast, and we are already preparing the third major release of the program (poke 3.x) which is scheduled for the end of the summer.

GNU poke is distributed in the form of a shared library (libpoke.so), a daemon (poked) and a command-line application (poke). The shared library, which provides the incremental compiler for the Poke language and the Poke Virtual Machine (PVM), is specifically designed to integrate poke in other applications.

In this talk we will be showing two examples of this that show how poke can be leveraged to improve the GNU Toolchain:

First, we integrated poke in GDB, the GNU debugger. This makes it possible for the GDB users to poke at the inferior's memory. The integration includes the ability of translating GDB types into Poke types. But a particularly useful use-case is when we need to poke at the contents of buffers in the inferior's memory for which we don't have type information in the debugger; an example of this is payloads in network packages:

   : (gdb) poke load tcp
   : (gdb) poke var p = TCP_Packet @ $addr::my_buffer
   : (gdb) poke p.hdr.bit2 = 0

Then there is the integrating of poke in GAS, the GNU assembler. This takes the form of a new assembler directive: `.poke'. This directive can then be used to assemble arbitrarily complex data structures. For example, instead of this:

   : .section .text
   : .set softfloat
   : .ascii "PS-X EXE"
   : .byte 0, 0, 0, 0, 0, 0, 0, 0
   : .word main
   : .word 0
   : .word 0x80010000
   : .word image_size
   : .word 0,0,0,0
   : .word 0x8001FFF0
   : .word 0,0,0,0,0,0
   : .ascii "Sony Computer Entertainment Inc. for zid"

We can write:

   : .section .text
   : .set softfloat
   : .poke load psxexe
   : .poke var s = "Sony Computer"
   : .poke PS_X_EXE { start = $main, size = $image_size, vendor = s }

Both GDB and GAS can of course use the many existing pickles around. In the talk, we would like to discuss and explore other toolchain areas/programs where poke may be useful, like generating testing data, documenting the several binary formats implemented by the tools, etc.

gprofng: The next generation GNU profiling tool

Speaker(s): Ruud van der Pas, Vladimir Mezentsev

In this talk we present an overview of gprofng, the next generation profiling tool for GNU/Linux. In March 2022, gprofng received the approval for inclusion in binutils and we are planning for gprofng to be part of 2.39 release.

This profiler has its roots in the Performance Analyzer from the Oracle Developer Studio product. Gprofng is a standalone tool however and specifically targets GNU/Linux. It includes several tools to collect and view the performance data. Various processors from Intel, AMD, and Arm are supported. The focus of gprofng is on applications written in C, C++, Java, and Scala. For C/C++ we assume GCC has been used to build the code. In the case of Java and Scala, OpenJDK and compatible implementations are supported.

Among other things, another difference with the widely known gprof tool is that gprofng offers full support for shared libraries and multithreading using Posix Threads, OpenMP, or Java Threads. Unlike gprof, gprofng can also be used in case the source code of the target executable is not available. Gprofng also works with unmodified executables. There is no need to recompile, or instrument the code. By profiling the production executable it is ensured that the profile reflects the actual run time behaviour and conditions of a production run.

After the data has been collected, the performance information can be viewed at the function, source, and disassembly level. Individual thread views are supported as well. Through command line options, the user specifies the information to be displayed. In addition to this, a simple, but yet powerful scripting feature can be used to produce a variety of performance reports in an automated way. This may also be combined with filters to zoom in on specific aspects of the profile. For example, it is very easy to zoom in on one or more threads, but also to compare the behaviour across threads.

One of the very powerful features of gprofng is the ability to compare two or more profiles. This allows for an easy way to spot regressions, or find scalability bottlenecks for example.

Two recent additions are the support for html based browsing of the profile information, and a GUI to graphically display and analyze the data.

The first of these features uses gprofng to generate an html based directory structure. This needs to be done on the target platform, but the results can be displayed and navigated on any platform using a standard browser. It is not necessary for gprofng to be available when browsing the results.

In case a more in-depth analysis is desired, the gprofng GUI is ideally suited to drill deeper into the data. In addition to display the basic profiling information, it also offers several views to provide more insight into the dynamic behaviour of the application. For example, to view the colour coded call stacks as a function of time. It also has full support to graphically compare profiles. The built-in filters can be used to zoom in on a specific time window and/or a subset of the threads used. If needed, the user can also define customized filters.

In the talk, we start with a description of the architecture of the gprofng tools suite. This is followed by an overview of the various tools that are available, plus the main features. A comparison with gprof will be made, but the bulk of the talk consists of examples to show the functionality and features. This includes the html functionality and GUI. We conclude with the plans for future developments.

Improving glibc with Restartable Sequences

Speaker(s): Mathieu Desnoyers

Slides: gnu-tools-cauldron-2022-improving-glibc-with-rseq.pdf

glibc 2.35 introduced support for the Restartable Sequences (rseq) system call in February 2022. It is initially used to speed up sched_getcpu(). There are various areas of glibc which can benefit from using rseq, the main contenders being the memory allocator, statistics counters, and the getcpu(2) API. Other projects such as tcmalloc have already started using rseq.

This presentation will discuss the extensions recently proposed to the rseq system call, how they impact glibc use-cases, and more generally which additional glibc use-cases can benefit from rseq and whether further extensions are needed.

If-Conversion for a Partially Predicated VLIW Architecture

Speaker(s): Benoît Dinechin

Slides: If-Conversion for a Partially Predicated VLIW Architecture

Kalray are producing manycore processors based on 'KVX' cores that implement a modern VLIW architecture ('vector-scalar' ISA as in IBM POWER, can be compiled like on-order superscalar, no VLIW templates). The main C/C++ compiler is a retargeting of GCC 10.

The talk proposal is about how to achieve aggressive if-conversion with the existing GCC ifcvt infrastructure. Below I outline what was done, and if of interest will reformat as an abstract for the talk.

The main challenge is that the KVX implements a Fisher-style VLIW architecture, which does not have a fully predicated ISA. Instead, only conditional load, store, and register moves are available. However one should note that most ISAs have a conditional register move, and from that it is possible to emulate conditional load and stores (conditional move of load returned value in a temporary, and conditional move of store address to a don't care stack location). So the talk is relevant to if-conversion even for cores that do not have superscalar implementation with hardware speculative execution.

In our case, aggressive if-conversion involves the predication of data moves, and the speculation of arithmetic instructions operating on registers without other side-effects.

The current GCC ifcvt infrastructure operates in three passes:

• CE1 for conditional register moves before combine
• CE2 for conditional register moves after combine
• CE3 for fully predicated ISA after reload

In particular, if-conversion of load and stores can only be performed by CE3.

Our approach is to have the ifcvt infrastructure do normal CE1 and CE2 conversion to conditional moves, and in addition extend CE2 to prepare for speculated execution and predicated execution by CE3. Then in CE3 the (cond_exec ) patterns proposed by (cond_exec_process_insns) and the insns marked for speculative execution enable further if-conversion. For this, the TARGET_HAVE_CONDITIONAL_EXECUTION implementation returns the value of reload_completed.

During the CE2 step where we prepare for CE3, for each instruction in a then_bb or else_bb there are four cases cases to consider:

1. the instruction can be cond_exec as is: register moves, memory load and stores whose addressing mode exist in the conditional form => provide a cond_exec variant of the pattern in machine description

2. memory load or store whose addressing mode is too complex for the conditional form => provide a parallel pattern with the original one and a clobber of a pseudo-register that will be used to compute the address

3. arithmetic instructions without side-effects whose SET_DEST register is not live-out => mark the insn as speculative

4. arithmetic instructions without side-effects whose SET_DEST register is live-out => provide a parallel pattern with the original one and a clobber of a pseudo-register that will be used in a conditional move

The patterns with the (parallel [(set ...) (clobber ...)]) clobber a temporary (pseudo-)register instead of a (scratch) because we need to ensure that register allocation will not use a hard registers that carry a value across blocks of the IF-THEN-ELSE-JOIN (or IF-THEN-JOIN) hammock. For each of these temporary registers we insert a (clobber ...) at the end of test_bb and a (use ...) at the start of join_bb to make them interfere with the non-local variables. In addition, we include a (use ..) of the tested register at the end of then_bb and else_bb so it will be available for CE3 predication in these blocks.

Now for the patterns used by CE3 we rely on split after reload and before sched2 (split4) to:

• either undo the wrapping of (parallel [(set ...) (clobber ...)]) done at CE2 in cases 1) and 3) by reverting to the original (set ..) pattern if the if-conversion of a particular hammock was not successful.
• or in case 1), split the (cond_exec ...) produced by (cond_exec_process_insns) into computing the address into the temporary register, then feeding it into the conditional form of the load store; the split preparation emits this address computation.
• or in case 2), remember that the insn was deemed speculative in CE2, and have IFCVT_MODIFY_INSN return the original pattern instead of the one proposed by (cond_exec_process_insns).
• or in case 3), where the (parallel [(set ...) (clobber ...)]) done in CE2 has been wrapped into a (cond_exec ..) by (cond_exec_process_insns), split into the original (set ...) targeting the temporary, followed by (cond_exec ...) move of this temporary into the original SET_DEST of the insn.

Although it appears robust and significantly improves performance on the KVX, currently this work has a few issues left:

• Flagging insns as speculative in CE2 so that CE3 (cond_exec_process_insns) does not wrap them in (cond_exec ...) is done by adding and checking REG_NONNEG, otherwise not used on our port. This is a hack.
• Creating the (cond_exec) patterns for the case 3) is tedious and error-prone so was automated by an ad-hoc script. Indeed, (define_cond_exec) does not apply because the resulting (cond_exec) should be a (define_insn_and_split) for cases 1) and 3). Same for (define_subst ...).

This work seems original, as most of published if-conversion work operates either on pseudo-registers or on SSA variables, e.g. see my survey of if-conversion techniques in CC'14 https://www.researchgate.net/publication/277404257_Using_the_SSA-Form_in_a_Code_Generator

Among the GCC 10 ports that exploit CE3, the FRV achieves CE3 if-conversion by scanning the register allocated code for available hard registers, then use them for reassigning CC registers and to compute temporary values such as addresses for conditional load/store. By contrast, we reserve hard registers for temporary computations by adding in CE2 (clobber ...) to the patterns of CE3 candidates, as the KVX has a register-rich ISA.

Morello GCC: bringing CHERI capabilities to the GNU toolchain

Speaker(s): Alex Coplan , Szabolcs Nagy

Slides: morello-gcc-cauldron-2022.pdf

Morello is a research program led by Arm and funded by the UK government’s Industrial Strategy Challenge Fund (ISCF) Digital Security by Design (DSbD) programme in which CHERI capabilities are introduced in an experimental fork of the Armv8-A architecture. These capabilities enable fine-grained memory protection and highly scalable software compartmentalization. Arm has designed a CPU and industrial demonstrator board which implements the Morello architecture.

As part of this work, we have been developing a port of the GNU toolchain to Morello. In this talk, we will introduce CHERI and Morello, dive into some of the far-reaching implications of introducing capabilities to the toolchain, and present what has been achieved to date.

New and Upcoming Hardening Features in GCC

Speaker(s): Alexandra Oliva

This talk will cover the design and implementation of several hardening features added in GCC 12, or yet to be contributed: registers and stack scrubbing, hardening of conditionals, control flow redundancy, and hardened booleans for Ada and C. It will also discuss challenges in the pursuit of target-independent implementations, and of testing features disabled by default.

OpenACC, OpenMP, Offloading and GCC

Speaker(s): Tobias Burnus, Thomas Schwinge, Andrew Stubbs

Slides: OpenMP-OpenACC-Offload-Cauldron2022-1.pdf

A short intoduction to OpenACC and OpenMP, their implementation status in GCC and features to be extended or still to be implemented of OpenACC up to 3.2 and OpenMP up to 5.2 – with the next releases/previews expected for later this year.

Additionally, an introduction in how offloading to an accelerator/GPU device is implemented in GCC, what is implemented there and what is missing or should be improved.

Ranger update

Speaker(s): Aldy Hernandez

Slides: 2022-ranger-update-Cauldron.pdf

This talk will give a summary of what's been going on in ranger land, and what we plan to include in next year's GCC 13. We will also briefly touch on what we would like to work in the future (GCC 14 and beyond).

Some of the upcoming things for this release include: (a) a range type agnostic framework, (b) an initial implementation for floating point range (c) fine grained global ranges (d) pointer ranges (e) enablement of ranger VRP for all VRP clients (f) removal of legacy VRP, plus other things....

Redesigning GDB's Ctrl-C handling

Speaker(s): Pedro Alves

Slides: Ctrl-C redesign.pdf

LWN.net coverage: https://lwn.net/Articles/909496/

Currently, on GNU/Linux GDB, it is not possible to use Ctrl-C to interrupt programs that block or ignore SIGINT. You type Ctrl-C, but nothing happens, the debug session gets stuck, and sometimes it is not possible to get back the prompt.

This session will explain why that does not work, why fixing this turns out to be important for the incoming AMD GPU target, and what is the plan to fix it. We will go over how GDB currently handles Ctrl-C for the different targets GDB supports, and for native GNU/Linux more in detail. We will talk about terminal sessions, session leaders, process groups, terminal settings, pseudo-terminals, controlled I/O flushing, ptrace, how GDB stops programs, and more.

Security Improvement in the GNU Toolchain

Speaker(s): Qing Zhao, Siddhesh Poyarekar

Multiple new security improvements were added to the latest GNU toolchain releases. These include stack variables auto-initialization in the GCC middle-end, __builtin_dynamic_object_size support in C and C++ frontends, source fortification (_FORTIFY_SOURCE) level 3 support in GLIBC, straight line speculation mitigation in the GCC X86 backend, and many other improvements.

The focus of this talk is on stack variables auto-initialization,__builtin_dynamic_object_size in GCC12, and source fortification (_FORTIFY_SOURCE) level 3 in GLIBC 2.34. We will also provide more information on several other security features in the latest GNU toolchain.

Starting from GCC12, GCC can initialize all stack variables implicitly, including paddings, through a new option -ftrivial-auto-var-init. This is intended to eliminate all classes of uninitialized stack variable flaws. Lack of explicit initialization will still warn when -Wuninitialized is active. The initial patch has been committed in an early stage of GCC12 in September 2021, followed by bug fixes and enhancement to complete the feature. The Linux Kernel has been configured to use this new feature to improve its security since then.

The _FORTIFY_SOURCE macro has been a key mitigation feature in the GNU C Library, supported by the __builtin_object_size builtin function implemented in GCC. The key limitation of this feature was that it relied on a constant size estimate for fortified objects and when one wasn't available, the objects would remain unfortified.

GLIBC 2.34 added support for a new fortification level (_FORTIFY_SOURCE=3), which uses the __builtin_dynamic_object_size builtin function, expanding the scope of fortification coverage to situations where a variable size estimate for objects can be computed. The __builtin_dynamic_object_size builtin was implemented in GCC 12, allowing Linux based distributions to be bootstrapped with this new fortification level.

In addition to the above major security improvements in the GNU toolchain, straight line speculation (SLS) mitigation for function return and indirect jump is supported on X86, "wipe call-used registers on return" (-fzero-call-used_regs) was enhanced to include more targets, and better code sequence on X86. The Static Analyzer also gained a set of nice improvements.

In the talk we provide a high-level overview of these new security features. This includes a description of the motivation, major challenges, new interfaces to the users, current status of the features, the performance impact, and existing known issues. We conclude with a sketch of future direction and further improvements of these security features under consideration.

Update on the Rust front-end

Speaker(s): Philip Herron, Arthur Cohen, David Faust

This talk will show the current state and progress of the front-end in terms of the upstreaming process and quality. A focus will be on managing the project, from patches to bug triage. Each author will discuss their area of interest, areas we can improve and ideas for the future.

Value Numbering in GCC

Speaker(s): Richard Biener

The talk presents the history around value numbering in GCC, focusing on most recent development providing a region-aware scalable utility.

Slides: 2022-Cauldron-Value-Numbering.pdf

Lightning Talks

Adding Zc* support to the GNU tool chain

Speaker(s): Nandni Jamnadas (speaker), Chen Jiawei, Sinan Lin, YuLong, Charlie Keaney, Pietra FT Madio

Adding a RISC-V extension to the GNU tool chain is becoming more routine. However there are challenges in supporting an architecture that is so configurable, and where the design is done in public, with many changes before stability is reached. Zc* itself breaks into a set of 7 sub-extensions (or possibly 10 sub-extensions), depending on how you count. It is a superset of the original C extension, leading to a challenging set of constraints on what combinations of extensions are permitted. There are associated demands on testing, not just of the individual instructions, but of the various possible combinations of instructions.

In this lightning talk we'll share the experience of a collaborative effort to add support for Zc* 0.70.4 support to the GNU tool chain between the Programming Languages and Compiler Team of the Chinese Academy of Sciences and Embecosm. We hope the experience will be of use to others adding extensions. We will conclude with the initial assessment of Zc* impact on code size using the Embench benchmark suite.

BoFs

Arm/AArch64 BoF

Speaker(s): Richard Earnshaw

The Arm and AArch64 BoF is an open session for discussing your issues and concerns on anything Arm related in the GNU toolchain. There is no fixed agenda!

We'll probably start with a brief overview of the work done in the past year and then focus on whatever seems to be the most interesting item within the group. If you have specific issues or uestions that you wish to raise, it might help if you can notify us in advance so that we can try to ensure that there is time to cover it.

BoF: OpenMP, OpenACC & Offloading

Speaker(s): Tobias Burnus, Jakub Jelinek, Thomas Schwinge, Andrew Stubbs

Slides: BoF-OpenMP-OpenACC-Offloading-Cauldron2022.pdf

BoF to discuss topics related to concurrency and offloading work onto accelerators.

In particular, implementation of missing OpenMP 5.0 to 5.2 and OpenACC 2.7 to 3.2 features and their support on AMD and Nvidia devices. Further more improving the performance both on the device-specific part as also offloading/Open*-aware optimizations, extending the offloading format to support multiple -march/-misa per offload type, improving the diagnostic, and extending the documentation.

Related topics and trends can also be discussed, be it base language concurrency features, offloading without using OpenMP/OpenACC, other accelerators.

Diversity and Inclusion

Speaker(s): Nathan Sidwell

A discussion on diversity and inclusivity and how GCC can do better.

IBM zSystems BoF

Speaker(s): Ilya Leoshkevich, Andreas Arnez

Discuss topics related to the s390x / IBM zSystems toolchain, including support for the new z16 machine:

• New hardware and CPU facilities; AI accelerator.
• Binutils / gcc support for the above.
• Valgrind challenges.

In-process unwinding BoF

Speaker(s): Florian Weimer

GCC 12 removed a multi-threading scalability bottleneck in the libgcc unwinder (for static unwinding data). In this session, we plan to discuss future performance provements: how to land the dynamic frame registration in trunk, how to address some low-hanging fruit in DWARF processing. We an also discuss reliability improvements for avoiding out-of-stack reads if there is interest.

BoF: Sourceware GNU Toolchain Infrastructure and beyond

Speaker(s): Mark Wielaard, Frank Eigler

The Sourceware infrastructure is continually improving. Just like our other services, such as bugzilla, mailinglists and git repos, we like to provide zero maintenance infrastructure for tracking and automation of patches, testing and analyzing testresults. This BoF is for everybody who likes to discuss (and wants to help with) automating the infrastructure to make contributing to our projects more fun and more productive.

Topics to discuss include the shared buildbot [1]. Whether we need more/other arches/distro support. Which builders are most beneficial to projects. How buildbot should report issues. Whether to use the buildbot to automate other tasks like updating documentation, websites, generate release tars or updating bugzilla. How to use git user try branches. Taking advantage of the Bunsen [2] testrun cluster analysis, per-testrun testcase search/browse engines, search operators, testsuite summary (vs detail) grids. Patch tracking using patchwork [3] integrated with buildbot and the CICD trybot [4]. How to use the sourcehut mirror [5]. And anything else that would make you more productive and happy contributing.

[1] https://builder.sourceware.org/
[2] https://builder.sourceware.org/testruns/
[3] https://patchwork.sourceware.org/
[4] https://sourceware.org/glibc/wiki/CICDDesign.
[5] https://sr.ht/~sourceware/

Slides: html markdown

GNU Toolchain Infrastructure and the GTI project:

Speaker(s): Carlos O'Donell, David Edelsohn

Slides: GNU Toolchain Infrastructure.pdf

The GDB BoF

Speaker(s): Pedro Alves

An opportunity for the GDB community to meet to discuss all things related to the GNU Debugger project.

The GNU C Library BoF

Speaker(s): Carlos O'Donell, Florian Weimer

Slides: GNU Tools Cauldron 2022 - The GNU C Library BoF.pdf

The GNU C Library is used as the C library in the GNU systems and many other systems with the Linux kernel. The library is primarily designed to be a portable and high performance C library. It aims to follows all relevant standards including ISO C17 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known.

This BoF aims to bring together developers of other components that have dependencies on glibc and glibc developers to talk about the following topics:

• Planning for glibc 2.37 and what work needs to be done between September 2022 and February 2023.
• Planning for glibc 2.38 and what work needs to be done between February 2023 and August 2023.
• Status of kernel syscall wrappers.
• Status of Patchwork pre-commit CI/CD.

... and more.

The LTO BoF

Speaker(s): Jan "Honza" Hubicka

A discussion of anything to do with Link Time Optimzation

The RISC-V BoF

Speaker(s): Kito Cheng, Jeremy Bennett, Palmer Dabbelt

An opportunity to discuss everything around the RISC-V tool chain.

• A bunch of new extensions are in flight, I'm sure there'll be stuff to talk about there -- whether it's for stuff that's ratified like B and V or for stuff that's still in draft like CFI (which may be another ABI).
• Vendor extensions. We'll likely have some simple stuff in by that point, but I very much doubt we've got anything concrete for the more complicated bits.
• This memory model stuff is likely to drag on for a while, doubly so if there's ABI issues.
• No idea where we'll stand WRT the psABI stuff, but I bet there'll be something to talk about.
• Also no idea if the proflies stuff will have gone anywhere by then, but again there'll likely be stuff to talk about.

The Sphinx Documentation BoF

Speaker(s): Martin Liška

A discussion about the current GCC's documentation and how can we improve it with a more modern documentation format called Sphinx. I'm going to make a demo presentation of the migrated documentation and we will discuss possible benefits and drawbacks.

Slides: cauldron-2022-docs-bof.pdf

Upstreaming the Rust front-end BoF

Speaker(s): Philip Herron, Arthur Cohen, Davd Faust

This BOF will continue from the talk to open a more in-depth discussion about the upstreaming process and how this is going. What can we do better?

Tutorials

None submitted

Q&A Sessions

GCC Steering Committee Q&A

Speaker(s): David Edelsohn

Let's talk about GNU Toolchain governance with the GCC Steering Committee, and GLIBC, GDB and Binutils Stewards!