(Presented in COSCUP 2022)
Debug information is a mapping between the original source code and low-level binary locations. It provides developers powerful insights to diagnose problems (via debuggers) in their code and acts as one of the most important foundations for modern software development. Furthermore, in recent years, we are seeing increasing demands of high quality debug information for highly optimized applications that are otherwise “un-debuggable”. For instance, debugging unoptimized games is generally not feasible since it’s likely to miss every single frame. In this talk, we are going to introduce how debug information works and how compilers generate proper debug info even with extensive levels of optimization enabled. At the end of this talk, you will gain insights into the structure of debug information and learn key compiler engineering knowledge on generating high quality debug info for critical, highly optimized software.
The document provides an overview of eBPF maps and how they can be used to share data between eBPF programs running in the kernel and userspace applications. It describes how maps are created via the BPF syscall using the BPF_MAP_CREATE command. It also explains how keys and values can be looked up, updated, and deleted from maps using commands like BPF_MAP_LOOKUP_ELEM, BPF_MAP_UPDATE_ELEM, and BPF_MAP_DELETE_ELEM. Finally, it lists the different types of eBPF maps available.
eBPF is an exciting new technology that is poised to transform Linux performance engineering. eBPF enables users to dynamically and programatically trace any kernel or user space code path, safely and efficiently. However, understanding eBPF is not so simple. The goal of this talk is to give audiences a fundamental understanding of eBPF, how it interconnects existing Linux tracing technologies, and provides a powerful aplatform to solve any Linux performance problem.
ATF(ARM Trusted Firmware)は、ARMv8では重要なソフトウェア。
全体を利用するのではなく、その一部を利用可能。
この資料では、BL31(EL3 Runtime Firmware)を単体で使う場合、どうすればいいのかを、Xilinx社のZynq UltraScale+ MPSoCを例に説明しています。
ATF (ARM Trusted Firmware) is an important software in ARMv8.
Instead of using the whole, part of it is available.
This document explains how to do when using BL31 (EL3 Runtime Firmware) alone, for example, with Xilinx's Zynq UltraScale + MPSoC.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
The document provides an overview of eBPF maps and how they can be used to share data between eBPF programs running in the kernel and userspace applications. It describes how maps are created via the BPF syscall using the BPF_MAP_CREATE command. It also explains how keys and values can be looked up, updated, and deleted from maps using commands like BPF_MAP_LOOKUP_ELEM, BPF_MAP_UPDATE_ELEM, and BPF_MAP_DELETE_ELEM. Finally, it lists the different types of eBPF maps available.
eBPF is an exciting new technology that is poised to transform Linux performance engineering. eBPF enables users to dynamically and programatically trace any kernel or user space code path, safely and efficiently. However, understanding eBPF is not so simple. The goal of this talk is to give audiences a fundamental understanding of eBPF, how it interconnects existing Linux tracing technologies, and provides a powerful aplatform to solve any Linux performance problem.
ATF(ARM Trusted Firmware)は、ARMv8では重要なソフトウェア。
全体を利用するのではなく、その一部を利用可能。
この資料では、BL31(EL3 Runtime Firmware)を単体で使う場合、どうすればいいのかを、Xilinx社のZynq UltraScale+ MPSoCを例に説明しています。
ATF (ARM Trusted Firmware) is an important software in ARMv8.
Instead of using the whole, part of it is available.
This document explains how to do when using BL31 (EL3 Runtime Firmware) alone, for example, with Xilinx's Zynq UltraScale + MPSoC.
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka, eBPF. It allows us to measure latency distributions for file system I/O and run queue latency, print details of storage device I/O and TCP retransmits, investigate blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. This talk will summarize this new technology and some long-standing issues that it can solve, and how we intend to use it at Netflix."
The document discusses QEMU and adding a new device to it. It begins with an introduction to QEMU and its uses. It then discusses setting up a development environment, compiling QEMU, and examples of existing devices. The main part explains how to add a new "Devix" device by creating source files, registering the device type, initializing PCI configuration, and registering memory regions. It demonstrates basic functionality like interrupts and I/O access callbacks. The goal is to introduce developing new emulated devices for QEMU.
ZynqMPのブートとパワーマネージメント : (ZynqMP Boot and Power Management)Mr. Vengineer
2016年2月20日(金)のZynq Ultrasclae+ MPSoC 勉強会で使った資料です。
追記) 2016.05.08
公式ARM Trusted Firmwareのサイトに、Zynq UltraScale+ MPSoCの実装が追加されていていることを明記した
This is the material I used at Zynq Ultrasclae + MPSoC SIG on 20th February (Friday).
Addendum) 2016.05.08
We stated that the implementation of Zynq UltraScale + MPSoC was added to the official ARM Trusted Firmware site.
The document discusses the LLVM compiler framework and infrastructure. It provides reusable components for building compilers to reduce the time and cost of building new compilers. The LLVM compiler framework uses the LLVM infrastructure to build static compilers, JITs, and trace-based optimizers. It emits C code or native code for x86, Sparc, and PowerPC architectures. The three primary LLVM components are the virtual instruction set (the common language- and target-independent intermediate representation), a collection of well-integrated libraries, and a collection of tools built from the libraries.
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract:
A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding uses for security auditing and enforcement, enhancing networking (including eXpress Data Path), and performance observability and troubleshooting. Many new open source tools that have been written in the past 12 months for performance analysis that use BPF. Tracing superpowers have finally arrived for Linux!
For its use with tracing, BPF provides the programmable capabilities to the existing tracing frameworks: kprobes, uprobes, and tracepoints. In particular, BPF allows timestamps to be recorded and compared from custom events, allowing latency to be studied in many new places: kernel and application internals. It also allows data to be efficiently summarized in-kernel, including as histograms. This has allowed dozens of new observability tools to be developed so far, including measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more.
This talk will summarize BPF capabilities and use cases so far, and then focus on its use to enhance Linux tracing, especially with the open source bcc collection. bcc includes BPF versions of old classics, and many new tools, including execsnoop, opensnoop, funcccount, ext4slower, and more (many of which I developed). Perhaps you'd like to develop new tools, or use the existing tools to find performance wins large and small, especially when instrumenting areas that previously had zero visibility. I'll also summarize how we intend to use these new capabilities to enhance systems analysis at Netflix.
Play with FILE Structure - Yet Another Binary Exploit TechniqueAngel Boy
The document discusses exploiting the FILE structure in C programs. It provides an overview of how file streams and the FILE structure work. Key points include that the FILE structure contains flags, buffers, a file descriptor, and a virtual function table. It describes how functions like fopen, fread, and fwrite interact with the FILE structure. It then discusses potential exploitation techniques like overwriting the virtual function table or FILE's linked list to gain control of program flow. It notes defenses like vtable verification implemented in modern libc libraries.
BPF of Berkeley Packet Filter mechanism was first introduced in linux in 1997 in version 2.1.75. It has seen a number of extensions of the years. Recently in versions 3.15 - 3.19 it received a major overhaul which drastically expanded it's applicability. This talk will cover how the instruction set looks today and why. It's architecture, capabilities, interface, just-in-time compilers. We will also talk about how it's being used in different areas of the kernel like tracing and networking and future plans.
Viller Hsiao presents information on Linux vsyscall and vDSO. vDSO (virtual dynamic shared object) is mapped into userspace and contains implementations of common system calls to make them faster. It gets benefits from ASLR and allows additional system calls compared to the older vsyscall method. The kernel generates the vDSO shared object which is then loaded and accessed by the glibc dynamic linker to provide optimized system call implementations to applications.
The code compares pointers and arrays in C by printing their sizes and string lengths. When a string literal is assigned to a pointer, sizeof(pointer) returns the pointer size rather than the string length, while sizeof(array) returns the full array size including the null terminator. strlen(pointer) and strlen(array) both return the string length excluding the null terminator. When an array is passed to a function, it converts to a pointer and sizeof then returns the pointer size rather than full array size.
The document discusses Linux I2C and its subsystems. It describes the Linux I2C bus driver which provides an API for I2C and SMBus transactions. It also covers I2C adapter drivers that interface between the bus driver and physical I2C controllers, the I2C-dev driver which provides a character device interface, and I2C client drivers.
The LLVM project is a collection of compiler and toolchain technologies, including an optimizer, code generators, and front-ends like llvm-gcc and Clang. The project aims to provide modular, reusable compiler components to reduce the time and cost of building compilers. It also seeks to implement modern compiler techniques to generate fast, optimized code. LLVM has been used to build fast C/C++ compilers like LLVM-GCC that show improvements in compilation speed and generated code quality compared to GCC.
Understanding a kernel oops and a kernel panicJoseph Lu
This document discusses Linux kernel oops and kernel panics. It explains that a kernel oops occurs when there is an illegal instruction or illegal memory access in kernel space, and will kill the offending process to keep the system running. A kernel panic means the system must stop immediately. Kernel oops can be caused by illegal instructions, unrecognized system calls, undefined CPU instructions, unknown data aborts, or prefetch aborts. These result in a call to the arm_notify_die() function and generate an oops. Illegal instructions that handle interrupt vectors can cause a panic directly. A kernel panic performs further actions like console output and stopping other CPUs before restarting or halting the system. Methods to capture crash
The Linux Block Layer - Built for Fast StorageKernel TLV
The arrival of flash storage introduced a radical change in performance profiles of direct attached devices. At the time, it was obvious that Linux I/O stack needed to be redesigned in order to support devices capable of millions of IOPs, and with extremely low latency.
In this talk we revisit the changes the Linux block layer in the
last decade or so, that made it what it is today - a performant, scalable, robust and NUMA-aware subsystem. In addition, we cover the new NVMe over Fabrics support in Linux.
Sagi Grimberg
Sagi is Principal Architect and co-founder at LightBits Labs.
lldb kann mehr als nur einfache Breakpoints oder po. In dem Vortrag zeigt Oliver Bayer, wie sich mit Hilfe von lldb Programmcode zur Ausführungszeit manipulieren lässt, ohne das hierfür der Sourcecode anzupassen ist. Sei es, damit Test- oder Debugcode nicht in die produktiv App gelangt, oder weil der Sourcecode für einen Teil der App nicht vorliegt.
Event: macoun, 04.10.2019
Speaker: Oliver Bayer, inovex
Mehr Tech-Vorträge: inovex.de/vortraege
Mehr Tech-Artikel: inovex.de/blog
Best Bugs from Games: Fellow Programmers' MistakesAndrey Karpov
George Gribkov will present on errors found in the code of popular games like System Shock, Doom 3, and osu!. He will discuss how his tool searches for code errors, provide examples of bugs detected, and conclude his presentation. The examples will showcase issues like unused variables, incorrect increment variables in for loops, null pointer dereferences, and misunderstandings of operators like ??. Corrections will be proposed to address the bugs.
The document discusses QEMU and adding a new device to it. It begins with an introduction to QEMU and its uses. It then discusses setting up a development environment, compiling QEMU, and examples of existing devices. The main part explains how to add a new "Devix" device by creating source files, registering the device type, initializing PCI configuration, and registering memory regions. It demonstrates basic functionality like interrupts and I/O access callbacks. The goal is to introduce developing new emulated devices for QEMU.
ZynqMPのブートとパワーマネージメント : (ZynqMP Boot and Power Management)Mr. Vengineer
2016年2月20日(金)のZynq Ultrasclae+ MPSoC 勉強会で使った資料です。
追記) 2016.05.08
公式ARM Trusted Firmwareのサイトに、Zynq UltraScale+ MPSoCの実装が追加されていていることを明記した
This is the material I used at Zynq Ultrasclae + MPSoC SIG on 20th February (Friday).
Addendum) 2016.05.08
We stated that the implementation of Zynq UltraScale + MPSoC was added to the official ARM Trusted Firmware site.
The document discusses the LLVM compiler framework and infrastructure. It provides reusable components for building compilers to reduce the time and cost of building new compilers. The LLVM compiler framework uses the LLVM infrastructure to build static compilers, JITs, and trace-based optimizers. It emits C code or native code for x86, Sparc, and PowerPC architectures. The three primary LLVM components are the virtual instruction set (the common language- and target-independent intermediate representation), a collection of well-integrated libraries, and a collection of tools built from the libraries.
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract:
A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding uses for security auditing and enforcement, enhancing networking (including eXpress Data Path), and performance observability and troubleshooting. Many new open source tools that have been written in the past 12 months for performance analysis that use BPF. Tracing superpowers have finally arrived for Linux!
For its use with tracing, BPF provides the programmable capabilities to the existing tracing frameworks: kprobes, uprobes, and tracepoints. In particular, BPF allows timestamps to be recorded and compared from custom events, allowing latency to be studied in many new places: kernel and application internals. It also allows data to be efficiently summarized in-kernel, including as histograms. This has allowed dozens of new observability tools to be developed so far, including measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more.
This talk will summarize BPF capabilities and use cases so far, and then focus on its use to enhance Linux tracing, especially with the open source bcc collection. bcc includes BPF versions of old classics, and many new tools, including execsnoop, opensnoop, funcccount, ext4slower, and more (many of which I developed). Perhaps you'd like to develop new tools, or use the existing tools to find performance wins large and small, especially when instrumenting areas that previously had zero visibility. I'll also summarize how we intend to use these new capabilities to enhance systems analysis at Netflix.
Play with FILE Structure - Yet Another Binary Exploit TechniqueAngel Boy
The document discusses exploiting the FILE structure in C programs. It provides an overview of how file streams and the FILE structure work. Key points include that the FILE structure contains flags, buffers, a file descriptor, and a virtual function table. It describes how functions like fopen, fread, and fwrite interact with the FILE structure. It then discusses potential exploitation techniques like overwriting the virtual function table or FILE's linked list to gain control of program flow. It notes defenses like vtable verification implemented in modern libc libraries.
BPF of Berkeley Packet Filter mechanism was first introduced in linux in 1997 in version 2.1.75. It has seen a number of extensions of the years. Recently in versions 3.15 - 3.19 it received a major overhaul which drastically expanded it's applicability. This talk will cover how the instruction set looks today and why. It's architecture, capabilities, interface, just-in-time compilers. We will also talk about how it's being used in different areas of the kernel like tracing and networking and future plans.
Viller Hsiao presents information on Linux vsyscall and vDSO. vDSO (virtual dynamic shared object) is mapped into userspace and contains implementations of common system calls to make them faster. It gets benefits from ASLR and allows additional system calls compared to the older vsyscall method. The kernel generates the vDSO shared object which is then loaded and accessed by the glibc dynamic linker to provide optimized system call implementations to applications.
The code compares pointers and arrays in C by printing their sizes and string lengths. When a string literal is assigned to a pointer, sizeof(pointer) returns the pointer size rather than the string length, while sizeof(array) returns the full array size including the null terminator. strlen(pointer) and strlen(array) both return the string length excluding the null terminator. When an array is passed to a function, it converts to a pointer and sizeof then returns the pointer size rather than full array size.
The document discusses Linux I2C and its subsystems. It describes the Linux I2C bus driver which provides an API for I2C and SMBus transactions. It also covers I2C adapter drivers that interface between the bus driver and physical I2C controllers, the I2C-dev driver which provides a character device interface, and I2C client drivers.
The LLVM project is a collection of compiler and toolchain technologies, including an optimizer, code generators, and front-ends like llvm-gcc and Clang. The project aims to provide modular, reusable compiler components to reduce the time and cost of building compilers. It also seeks to implement modern compiler techniques to generate fast, optimized code. LLVM has been used to build fast C/C++ compilers like LLVM-GCC that show improvements in compilation speed and generated code quality compared to GCC.
Understanding a kernel oops and a kernel panicJoseph Lu
This document discusses Linux kernel oops and kernel panics. It explains that a kernel oops occurs when there is an illegal instruction or illegal memory access in kernel space, and will kill the offending process to keep the system running. A kernel panic means the system must stop immediately. Kernel oops can be caused by illegal instructions, unrecognized system calls, undefined CPU instructions, unknown data aborts, or prefetch aborts. These result in a call to the arm_notify_die() function and generate an oops. Illegal instructions that handle interrupt vectors can cause a panic directly. A kernel panic performs further actions like console output and stopping other CPUs before restarting or halting the system. Methods to capture crash
The Linux Block Layer - Built for Fast StorageKernel TLV
The arrival of flash storage introduced a radical change in performance profiles of direct attached devices. At the time, it was obvious that Linux I/O stack needed to be redesigned in order to support devices capable of millions of IOPs, and with extremely low latency.
In this talk we revisit the changes the Linux block layer in the
last decade or so, that made it what it is today - a performant, scalable, robust and NUMA-aware subsystem. In addition, we cover the new NVMe over Fabrics support in Linux.
Sagi Grimberg
Sagi is Principal Architect and co-founder at LightBits Labs.
lldb kann mehr als nur einfache Breakpoints oder po. In dem Vortrag zeigt Oliver Bayer, wie sich mit Hilfe von lldb Programmcode zur Ausführungszeit manipulieren lässt, ohne das hierfür der Sourcecode anzupassen ist. Sei es, damit Test- oder Debugcode nicht in die produktiv App gelangt, oder weil der Sourcecode für einen Teil der App nicht vorliegt.
Event: macoun, 04.10.2019
Speaker: Oliver Bayer, inovex
Mehr Tech-Vorträge: inovex.de/vortraege
Mehr Tech-Artikel: inovex.de/blog
Best Bugs from Games: Fellow Programmers' MistakesAndrey Karpov
George Gribkov will present on errors found in the code of popular games like System Shock, Doom 3, and osu!. He will discuss how his tool searches for code errors, provide examples of bugs detected, and conclude his presentation. The examples will showcase issues like unused variables, incorrect increment variables in for loops, null pointer dereferences, and misunderstandings of operators like ??. Corrections will be proposed to address the bugs.
Как работает LLVM бэкенд в C#. Егор Богатов ➠ CoreHard Autumn 2019corehard_by
LLVM содержит огромное количество оптимизаций и подходит в качестве бэкенда для многих языков программирования. Но все немного усложняется для Managed языков и JIT сценариев. В этом докладе Егор расскажет о трудностях, с которыми столкнулись в C# при реализации LLVM бэкенда.
The X-Ray Engine is a game engine, used in the S.T.A.L.K.E.R. game series. Its code was made public in September 16 2014, and since then, STALKER fans continue its development. A large project size, and a huge number of bugs in the games, gives us a wonderful chance to show what PVS-Studio is capable of.
Самые вкусные баги из игрового кода: как ошибаются наши коллеги-программисты ...DevGAMM Conference
Один из лучших способов снизить количество багов в играх – это показывать программистам, как не стоит писать код. В своём докладе я соберу самые вкусные и необычные ошибки, которые удалось найти в C++ и C# коде таких игр, как VVVVVV, Space Engineers, Command & Conquer, osu! и даже Doom. Я уверен, что каждый из слушателей обязательно узнает для себя что-то новое. В конце концов, это просто приятно – лично увидеть ошибки из кода знакомой и любимой игры!
The document discusses various compiler data structure nodes used in the Java HotSpot VM compiler such as Node, RegionNode, PhiNode, and LoopNode. It describes how nodes are connected and how methods like Ideal, Value, and Identity are used to optimize nodes. The nodes represent an intermediate representation of the code during compilation and are manipulated throughout the various phases of compilation.
The document discusses floating point arithmetic. It describes the IEEE-754 single and double precision floating point formats which use 1 sign bit, a biased exponent field, and a significand field to represent values. It provides examples of how positive and negative floating point numbers are represented internally in binary and decoded to determine the sign, true exponent, and significand to calculate the base 10 value. The document also mentions an upcoming exam and provides project due dates.
Analysis of Haiku Operating System (BeOS Family) by PVS-Studio. Part 2PVS-Studio
The document summarizes analysis of the Haiku operating system using the PVS-Studio static analyzer. Various bugs and issues were detected, including: incorrect string handling, bad loops, improper use of variables with the same name, array overruns, unsafe memory handling, and other logical errors. The analyzer identified multiple areas for improvement to enhance code quality and eliminate potential bugs.
1) SCORE is a smart contract platform on ICON that allows developers to write, deploy and interact with smart contracts using Python.
2) T-Bears is a SCORE development suite that provides tools to develop, test, deploy and interact with SCORE contracts. It includes a CLI, sample templates and supports local emulation of contract execution.
3) SCORE contracts are deployed to and run on the ICON blockchain. They can store data on-chain, be invoked by transactions to update state, and trigger events.
This document contains 3 solutions to C++ programming problems involving basic data types and classes.
Solution 1 defines a phone number struct and demonstrates initializing instances, getting user input, and outputting phone numbers. Solution 2 defines a point struct and shows adding the x and y coordinates of two points to find the sum. Solution 3 defines a Rectangle class with private width and length variables, and public methods to set/get dimensions and calculate perimeter and area, demonstrating default values and bounds checking.
This time it was the microcosm that brought us a few interesting bugs. We have checked the open-source project μManager with our analyzer PVS-Studio. This project is a software package for automated microscope image acquisition.
Hot Code is Faster Code - Addressing JVM Warm-upMark Price
What is the JVM warm-up problem, and how does it affect our software? How can we aid the runtime in optimising our programs, and is it even a good idea to do so?
This presentation explores the lifecycle of Java code, and how the JVM evolves the runtime representation of code during program execution. From bytecode to assembly and back again (via some uncommon traps), we will cover practical tips on ensuring that Java code is running fast when it matters most.
The document provides an overview of programming concepts in C# including variables, data types, operators, decision making statements, and examples of code. It discusses if/else statements, switch statements, nested if statements, arithmetic operators, relational operators, logical operators, and assignment operators. It also includes examples of code for basic math operations, checking conditions, and taking user input. The document is intended to review fundamental C# concepts.
Static analysis and writing C/C++ of high quality code for embedded systemsAndrey Karpov
This document discusses static analysis for improving code quality in embedded systems. It begins by introducing the speaker and providing background on trends in IoT devices and code size growth. Examples are given of potential errors like divide by zero, use of uninitialized variables, and returning addresses of stack variables. Frameworks for finding vulnerabilities like CWE and real vulnerabilities like CVE are described. The value of code reviews and dynamic analysis are discussed but their limitations for embedded code. Finally, standards like MISRA and SEI CERT for preventing errors and examples of correctly using static analysis are provided.
AspectJ is a technology that allows programmers to modularize crosscutting concerns in Java programs using aspects. Aspects define pointcuts that match certain join points in the execution of a program, and advice that specifies actions to take at those join points. Pointcuts, advice, and aspects provide a way to implement crosscutting functionality separately from the core program logic.
We have successfully created and continue developing PVS-Studio analyzer for C/C++ languages. Over the time, it became clear that many of the diagnostics that we have implemented are not related to a specific programming language, so we decided to apply our experience to another programming language, namely C#. In this article, we are talking about the analysis of Code Contracts project by Microsoft done by our C# analyzer
The document contains 27 code examples that demonstrate various programming concepts in C++, including:
1. Printing numeric patterns using nested for loops.
2. Finding the largest number among 3 inputs using if/else statements and functions.
3. Calculating factorials, prime numbers, Fibonacci sequences and number tables using for loops.
4. Checking if a number is even/odd using if/else.
5. Illustrating the use of classes to store student data like roll numbers and marks in multiple subjects.
6. Defining functions both inside and outside classes to get/set data member values.
The code snippets cover basic programming constructs like loops, functions, classes,
C++ and OOPS Crash Course by ACM DBIT | Grejo JobyGrejoJoby1
The slides from the C++ and OOPS Crash Course conducted for ACM DBIT by Grejo Joby.
Learn the concepts of OOPS and C++ Programming in the shortest time with these notes.
The document describes monadic parsers and how they can be implemented using functional programming concepts like functors, applicatives, and monads. It shows how parser combinators can be built to parse input using techniques like binding, alternative parsing, and between operators. Examples demonstrate parsing employee records and expressions using monadic parsers.
1. The document contains code for 8 programming experiments involving algorithms for calculating simple and compound interest, determining Armstrong and Fibonacci numbers, finding the roots of a quadratic equation, matrix operations, and sorting arrays.
2. The algorithms are presented step-by-step and the C code to implement each algorithm is included and commented.
3. Sample inputs and outputs are provided for each program to demonstrate its functionality.
Similaire à Debug Information And Where They Come From (20)
Estimating instruction-level throughput (for example, predicting the cycle counts) is critical for many applications that rely on tightly calculated and accurate timing bounds. In this talk, we will present a new throughput analysis tool, MCA Daemon (MCAD). It is built on top of LLVM MCA and combines the advantages of both static and dynamic throughput analyses, providing a powerful, fast, and easy-to-use tool that scales up with large-scale programs in the real world.
Handling inline assembly in Clang and LLVMMin-Yih Hsu
The document discusses how inline assembly is processed in Clang and LLVM. It outlines the target-specific logic involved at each stage, including operand constraint validation in Clang, lowering operands to LLVM IR, and printing different operand types in the assembler. Target-specific callbacks for inline assembly handling are scattered throughout Clang and LLVM. The goals are to learn the inline assembly workflow and provide documentation for backend developers to add support.
The document describes a presentation on writing a TableGen backend. It introduces TableGen as a domain-specific language originated from LLVM to describe instruction tables and other target-specific data in a declarative way. TableGen backends generate target code from TableGen input. The presentation discusses using TableGen records to represent data, differences between OOP and TableGen, TableGen data types, and provides an example of how TableGen is used in LLVM backends to generate code from the table description files for targets.
[COSCUP 2021] LLVM Project: The Good, The Bad, and The UglyMin-Yih Hsu
The document provides an overview of Min Hsu's talk on the LLVM Project. It introduces Min Hsu and their background working on LLVM. The talk covers an overview of LLVM's design advantages over traditional compilers, some new features like GlobalISel and ThinLTO that improve compilation speed and optimization, and notes on LLVM's federated community structure and contribution process.
[TGSA Academic Friday] How To Train Your Dragon - Intro to Modern Compiler Te...Min-Yih Hsu
The original talk was presented in TGSA (http://clubs.uci.edu/tgsa/) Academic Friday, December 6th 2020.
Most of the contents are written in English. Except some Chinese memes.
Paper Study - Demand-Driven Computation of Interprocedural Data FlowMin-Yih Hsu
This paper presents a demand-driven approach to inter-procedural data flow analysis that avoids generating redundant analysis results by only computing the necessary data flow facts needed to answer specific queries. The algorithm performs a reverse data flow analysis starting from the query point using a reverse flow function. This approach can answer queries more efficiently than traditional exhaustive data flow analysis.
Souper-Charging Peepholes with Target Machine InfoMin-Yih Hsu
# LLVM Dev Meeting 2019 - Bay Area
Souper, a LLVM-based superoptimization framework, has seen adoption in both academic research and industry projects. Given an LLVM IR as an input, Souper tries to generate peephole patterns by synthesizing semantically equivalent but shorter instruction sequences. However, as a platform-independent framework, it lacks a model of the actual cost of an instruction sequence on the target machine. This leads to missing optimizations opportunities or generation of peephole patterns which degrade performance.
In this talk, we’re going to demonstrate how Souper can benefit from target machine information. Then, we will explore some possible approaches to providing Souper with target machine info to steer the superoptimizer to find more patterns with improvements than regressions. This will enable Souper to be used in a more automated way and reduce the manual intervention required.
This document summarizes a talk about modern compiler techniques using Google's V8 JavaScript engine as an example. It discusses how early JavaScript interpreters led to slow execution speeds due to CPU pipeline stalling and lack of optimizations. Just-in-time (JIT) compilation was introduced to compile code on the fly and apply more optimizations. V8 uses a unified graph-based intermediate representation (IR) that allows optimizations and instruction selection by reducing the graph. The document contrasts traditional compiler courses with skills needed for real-world compiler projects, like those used at V8, which involve extensive optimizations, instruction selection, and dealing with dynamic types.
SYCL (Khronos SYCL) is an open standard for single-source heterogeneous programming that uses C++ templates. It aims to provide a more native C++ interface for OpenCL-like programming while retaining compatibility with OpenCL. The key aspects covered are the SYCL programming model which supports most C++11/14 features, its single-source approach across devices, and memory model including shared virtual memory. However, it currently lacks official implementations and support is mainly through the triSYCL library.
Trace scheduling involves forming larger regions called traces from multiple basic blocks to improve instruction scheduling. Traces are constructed by following the most likely path through conditional branches. Optimizations like speculative code motion can then move instructions across branches within the trace. Compensation code may be needed to fix program semantics when instructions are speculatively moved or code is duplicated. The goal is to avoid branches and exploit a larger scheduling region for more optimization opportunities than single basic blocks.
Bekket McClane gave a presentation on Polymer, an open-source JavaScript library for building web components. Polymer allows developers to create reusable custom elements called modules through techniques like data binding and event handling. Modules are defined separately and can then be implemented on pages through registration. Polymer uses concepts from Shadow DOM to encapsulate components and separate structure from presentation. While Polymer enables powerful component-based development, its learning curve can be long and cross-browser performance and lack of a central element library are drawbacks.
War of Native Speed on Web (SITCON2016)Min-Yih Hsu
This document discusses efforts to improve the performance of JavaScript for web applications. It introduces ASM.JS, a subset of JavaScript that can be optimized to perform closer to native machine code by taking advantage of static typing. It also discusses Native Client (NaCl) and Portable Native Client (PNaCl), which allow C and C++ code to be run securely in the browser by compiling to an intermediate representation. Finally, it introduces WebAssembly as a new binary format for code that aims to be faster than JavaScript, have an AST-like structure, and support being run directly in the browser or through just-in-time compilation. The document argues that while JavaScript will still be important for web pages, it may no longer
Bekket McClane gave a presentation on moving from the Android NDK to AOSP. The presentation covered the Android NDK introduction and JNI programming. It provided an overview of AOSP including the zygote process and Binder IPC. An example was shown for controlling the vibrator using C/C++ Binder APIs by accessing libraries from AOSP. The steps included building AOSP libraries, creating an Android.mk file, and interacting with the vibrator service via a fake AIDL interface. Questions were invited via the speaker's online accounts.
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
Drona Infotech is a premier mobile app development company in Noida, providing cutting-edge solutions for businesses.
Visit Us For : https://www.dronainfotech.com/mobile-application-development/
What to do when you have a perfect model for your software but you are constrained by an imperfect business model?
This talk explores the challenges of bringing modelling rigour to the business and strategy levels, and talking to your non-technical counterparts in the process.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
SMS API Integration in Saudi Arabia| Best SMS API ServiceYara Milbes
Discover the benefits and implementation of SMS API integration in the UAE and Middle East. This comprehensive guide covers the importance of SMS messaging APIs, the advantages of bulk SMS APIs, and real-world case studies. Learn how CEQUENS, a leader in communication solutions, can help your business enhance customer engagement and streamline operations with innovative CPaaS, reliable SMS APIs, and omnichannel solutions, including WhatsApp Business. Perfect for businesses seeking to optimize their communication strategies in the digital age.
WWDC 2024 Keynote Review: For CocoaCoders AustinPatrick Weigel
Overview of WWDC 2024 Keynote Address.
Covers: Apple Intelligence, iOS18, macOS Sequoia, iPadOS, watchOS, visionOS, and Apple TV+.
Understandable dialogue on Apple TV+
On-device app controlling AI.
Access to ChatGPT with a guest appearance by Chief Data Thief Sam Altman!
App Locking! iPhone Mirroring! And a Calculator!!
Top 9 Trends in Cybersecurity for 2024.pptxdevvsandy
Security and risk management (SRM) leaders face disruptions on technological, organizational, and human fronts. Preparation and pragmatic execution are key for dealing with these disruptions and providing the right cybersecurity program.
SOCRadar's Aviation Industry Q1 Incident Report is out now!
The aviation industry has always been a prime target for cybercriminals due to its critical infrastructure and high stakes. In the first quarter of 2024, the sector faced an alarming surge in cybersecurity threats, revealing its vulnerabilities and the relentless sophistication of cyber attackers.
SOCRadar’s Aviation Industry, Quarterly Incident Report, provides an in-depth analysis of these threats, detected and examined through our extensive monitoring of hacker forums, Telegram channels, and dark web platforms.
Most important New features of Oracle 23c for DBAs and Developers. You can get more idea from my youtube channel video from https://youtu.be/XvL5WtaC20A
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
E-Invoicing Implementation: A Step-by-Step Guide for Saudi Arabian CompaniesQuickdice ERP
Explore the seamless transition to e-invoicing with this comprehensive guide tailored for Saudi Arabian businesses. Navigate the process effortlessly with step-by-step instructions designed to streamline implementation and enhance efficiency.
20. Example Input
8
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
*Host Architecture: x86_64
21. Example Input
8
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
$ cc -g -c demo.c -o demo.o
*Host Architecture: x86_64
22. Example Input
8
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
$ cc -g -c demo.c -o demo.o
$ llvm-dva demo.o …
*Host Architecture: x86_64
23. llvm-dva: Visualizing Debug Info
9
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
24. llvm-dva: Visualizing Debug Info
10
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
25. llvm-dva: Visualizing Debug Info
10
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
26. llvm-dva: Visualizing Debug Info
11
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
27. llvm-dva: Visualizing Debug Info
11
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
28. llvm-dva: Visualizing Debug Info
12
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Line numbers & instructions
29. llvm-dva: Visualizing Debug Info
12
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Line numbers & instructions
30. llvm-dva: Visualizing Debug Info
12
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Where ‘c’ is stored
Line numbers & instructions
31. llvm-dva: Visualizing Debug Info
12
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Where ‘c’ is stored
PC Address Line Number
Assembly
(NOT stored in debug info)
0x1C 5 cmpl $0x0,-0x18(%rbp)
0x20 5 je 0xc
Line numbers & instructions
32. llvm-dva: Visualizing Debug Info
13
{CompileUnit} ‘demo.c'
....
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
....
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
3 {Line}
{Code} 'endbr64'
{Code} 'pushq %rbp'
....
4 {Line}
{Code} 'movl $0x0, -0x8(%rbp)'
{Code} 'movl $0x0, -0x4(%rbp)'
5 {Line}
{Code} 'cmpl $0x0, -0x18(%rbp)'
{Code} 'je 0xc’
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
33. llvm-dva: Visualizing Debug Info
14
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Variable locations
34. llvm-dva: Visualizing Debug Info
14
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
Variable locations
35. llvm-dva: Visualizing Debug Info
15
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Variable locations
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
Current Stack Frame
Lo Address
Hi Address
36. llvm-dva: Visualizing Debug Info
15
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Variable locations
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
Current Stack Frame
Lo Address
Hi Address
fbreg
37. llvm-dva: Visualizing Debug Info
15
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Variable locations
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
-24
Current Stack Frame
Lo Address
Hi Address
fbreg
38. llvm-dva: Visualizing Debug Info
15
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Variable locations
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
-24
-36
Current Stack Frame
Lo Address
Hi Address
fbreg
39. llvm-dva: Visualizing Debug Info
15
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Variable locations
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
-24
-36
-40
Current Stack Frame
Lo Address
Hi Address
fbreg
40. llvm-dva: Visualizing Debug Info
16
{CompileUnit} ‘demo.c'
1 {Struct} 'Point'
1 {Member} public 'x' -> 'int'
{Location}
{Entry} offset 0
1 {Member} public 'y' -> 'int'
{Location}
{Entry} offset 4
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Type Layout
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
Current Stack Frame
Lo Address
Hi Address
41. llvm-dva: Visualizing Debug Info
16
{CompileUnit} ‘demo.c'
1 {Struct} 'Point'
1 {Member} public 'x' -> 'int'
{Location}
{Entry} offset 0
1 {Member} public 'y' -> 'int'
{Location}
{Entry} offset 4
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Type Layout
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
Current Stack Frame
Lo Address
Hi Address
42. llvm-dva: Visualizing Debug Info
16
{CompileUnit} ‘demo.c'
1 {Struct} 'Point'
1 {Member} public 'x' -> 'int'
{Location}
{Entry} offset 0
1 {Member} public 'y' -> 'int'
{Location}
{Entry} offset 4
3 {Function} extern not_inlined 'foo' -> 'int'
3 {Parameter} 'k' -> 'int'
{Location}
{Entry} fbreg -36
3 {Parameter} 'c' -> 'int'
{Location}
{Entry} fbreg -40
4 {Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
Type Layout
Variable ‘point’
Variable ‘k’
Variable ‘c’
Previous Frame Ptr
Return Address
Current Stack Frame
Lo Address
Hi Address
Field ‘x’
Field ‘y’
+0
+4
49. Debug Info Standards
18
DWARF CodeView
• Default format in Linux, Apple platforms,
most of the Unix
• Supported by GNU & LLVM toolchain
50. Debug Info Standards
18
DWARF CodeView
• Default format in Linux, Apple platforms,
most of the Unix
• Supported by GNU & LLVM toolchain
• Container formats: DWO, DWP, dSYM
51. Debug Info Standards
18
DWARF CodeView
• Default format in Linux, Apple platforms,
most of the Unix
• Supported by GNU & LLVM toolchain
• Container formats: DWO, DWP, dSYM
• Default format in Windows (MSVC)
52. Debug Info Standards
18
DWARF CodeView
• Default format in Linux, Apple platforms,
most of the Unix
• Supported by GNU & LLVM toolchain
• Container formats: DWO, DWP, dSYM
• Default format in Windows (MSVC)
• Supported by MSVC & LLVM toolchain
53. Debug Info Standards
18
DWARF CodeView
• Default format in Linux, Apple platforms,
most of the Unix
• Supported by GNU & LLVM toolchain
• Container formats: DWO, DWP, dSYM
• Default format in Windows (MSVC)
• Supported by MSVC & LLVM toolchain
• Container format: PDB
58. Compilation Pipeline: A Crash Course
21
Source Code
AST
Parse
Intermediate
Representation
(IR)
Native Code
(e.g. *.o
fi
les)
59. Compilation Pipeline: A Crash Course
21
Source Code
AST
Parse
Intermediate
Representation
(IR)
Another
Intermediate
Representation
Native Code
(e.g. *.o
fi
les)
60. Debug Info in a Compilation Pipeline: Highlights
22
Source Code
AST
Parse
Intermediate
Representation
(IR)
Another
Intermediate
Representation
Native Code
(e.g. *.o
fi
les)
61. Debug Info in a Compilation Pipeline: Highlights
22
Source Code
AST
Parse
Intermediate
Representation
(IR)
Another
Intermediate
Representation
Native Code
(e.g. *.o
fi
les)
• How to “carry” debug info in IR ?
62. Debug Info in a Compilation Pipeline: Highlights
22
Source Code
AST
Parse
Intermediate
Representation
(IR)
Another
Intermediate
Representation
Native Code
(e.g. *.o
fi
les)
• How to “carry” debug info in IR ?
• Correctly translate from source to debug info in IR
63. Debug Info in a Compilation Pipeline: Highlights
22
Source Code
AST
Parse
Intermediate
Representation
(IR)
Another
Intermediate
Representation
Native Code
(e.g. *.o
fi
les)
• How to “carry” debug info in IR ?
• Correctly translate from source to debug info in IR
• Preserve debug info across transformations (e.g. optimizations)
64. Case Study: LLVM / Clang
23
void foo() {
int x = 9;
int y = 4;
}
C Source (foo.c)
65. Case Study: LLVM / Clang
23
define void @foo() {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1
store i32 4, i32* %2
ret void
}
void foo() {
int x = 9;
int y = 4;
}
C Source (foo.c)
LLVM IR (foo.ll)
$ clang -emit-llvm -S foo.c -o foo.ll
66. Case Study: LLVM / Clang
23
define void @foo() {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1
store i32 4, i32* %2
ret void
}
void foo() {
int x = 9;
int y = 4;
}
C Source (foo.c)
LLVM IR (foo.ll)
$ clang -emit-llvm -S foo.c -o foo.ll
Allocating stack space
67. Case Study: LLVM / Clang
23
define void @foo() {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1
store i32 4, i32* %2
ret void
}
void foo() {
int x = 9;
int y = 4;
}
C Source (foo.c)
LLVM IR (foo.ll)
$ clang -emit-llvm -S foo.c -o foo.ll
70. Debug Info in LLVM IR
25
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1, !dbg !13
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
void foo() {
int x = 9;
int y = 4;
}
C Source
1
2
3
4
LLVM IR
71. Debug Info in LLVM IR
25
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1, !dbg !13
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
void foo() {
int x = 9;
int y = 4;
}
C Source
1
2
3
4
LLVM IR
72. Debug Info in LLVM IR
25
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1, !dbg !13
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
void foo() {
int x = 9;
int y = 4;
}
C Source
1
2
3
4
LLVM IR
!13 = !DILocation(line: 2, column: 7, ...) At the bottom of IR
fi
le
73. Debug Info in LLVM IR
25
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
store i32 9, i32* %1, !dbg !13
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
void foo() {
int x = 9;
int y = 4;
}
C Source
1
2
3
4
LLVM IR
!13 = !DILocation(line: 2, column: 7, ...)
!15 = !DILocation(line: 3, column: 7, ...)
At the bottom of IR
fi
le
74. Debug Info in LLVM IR
26
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
call void @llvm.dbg.declare(metadata i32* %1, metadata !11, …), !dbg !13
store i32 9, i32* %1, !dbg !13
call void @llvm.dbg.declare(metadata i32* %2, metadata !14, …), !dbg !15
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
LLVM IR
75. Debug Info in LLVM IR
27
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
call void @llvm.dbg.declare(metadata i32* %1, metadata !11, …), !dbg !13
store i32 9, i32* %1, !dbg !13
call void @llvm.dbg.declare(metadata i32* %2, metadata !14, …), !dbg !15
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
LLVM IR
76. Debug Info in LLVM IR
27
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
call void @llvm.dbg.declare(metadata i32* %1, metadata !11, …), !dbg !13
store i32 9, i32* %1, !dbg !13
call void @llvm.dbg.declare(metadata i32* %2, metadata !14, …), !dbg !15
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
LLVM IR
!11 = !DILocalVariable(name: "x", ..., line: 2, ...)
77. Debug Info in LLVM IR
27
define void @foo() !dbg !7 {
%1 = alloca i32
%2 = alloca i32
call void @llvm.dbg.declare(metadata i32* %1, metadata !11, …), !dbg !13
store i32 9, i32* %1, !dbg !13
call void @llvm.dbg.declare(metadata i32* %2, metadata !14, …), !dbg !15
store i32 4, i32* %2, !dbg !15
ret void, !dbg !16
}
LLVM IR
!11 = !DILocalVariable(name: "x", ..., line: 2, ...)
96. Debugging Optimized Programs
• Games
• Di
ffi
cult (if not nearly impossible) to debug low-FPS games
• Embedded systems
• Size optimization is usually a hard requirement
33
97. Debugging Optimized Programs
• Games
• Di
ffi
cult (if not nearly impossible) to debug low-FPS games
• Embedded systems
• Size optimization is usually a hard requirement
• Easier debugging on release binaries
• E.g. Using core
fi
les directly from customers
33
98. Recall: Early Example Code
34
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
$ clang -g foo.c -emit-llvm -S
111. Preserving Debug Info in Optimized Code
• Most modern compilers preserve debug information as part of the code
transformations (e.g. optimizations)
43
112. Preserving Debug Info in Optimized Code
• Most modern compilers preserve debug information as part of the code
transformations (e.g. optimizations)
• Challenges
43
113. Preserving Debug Info in Optimized Code
• Most modern compilers preserve debug information as part of the code
transformations (e.g. optimizations)
• Challenges
• It’s easy for compiler developers to forget to handle debug info
43
114. Preserving Debug Info in Optimized Code
• Most modern compilers preserve debug information as part of the code
transformations (e.g. optimizations)
• Challenges
• It’s easy for compiler developers to forget to handle debug info
• It’s not possible to (faithfully) map optimized code back to source
locations in every cases
43
115. Preserving Debug Info in Optimized Code
• Most modern compilers preserve debug information as part of the code
transformations (e.g. optimizations)
• Challenges
• It’s easy for compiler developers to forget to handle debug info
• It’s not possible to (faithfully) map optimized code back to source
locations in every cases
• Debug info in optimized binaries is preserved on a best-e
ff
ort basis
43
144. Preserving Debug Locations in LLVM
57
Principles
• Don’t create misleading debug locations that are only correct in some cases
Actions
Keep Merge Delete
145. Preserving Debug Locations in LLVM
57
Principles
• Don’t create misleading debug locations that are only correct in some cases
• If you’re not sure, just drop the debug locations
Actions
Keep Merge Delete
146. Preserving Debug Locations in LLVM
57
Principles
• Don’t create misleading debug locations that are only correct in some cases
• If you’re not sure, just drop the debug locations
• Otherwise, preserve as much debug locations as possible
Actions
Keep Merge Delete
147. Debug Locations in our Example Code
58
define i32 @foo(i32 %0, i32 %1) {
%3 = icmp eq i32 %1, 0
%4 = select i1 %3, i32 0, i32 %0
%5 = add nsw i32 %4, %1
ret i32 %5
}
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
148. Debug Locations in our Example Code
59
define i32 @foo(i32 %0, i32 %1) {
%3 = icmp eq i32 %1, 0
%4 = select i1 %3, i32 0, i32 %0
%5 = add nsw i32 %4, %1
ret i32 %5
}
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
149. Debug Locations in our Example Code
59
define i32 @foo(i32 %0, i32 %1) {
%3 = icmp eq i32 %1, 0
%4 = select i1 %3, i32 0, i32 %0
%5 = add nsw i32 %4, %1
ret i32 %5
}
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
line 6 will only hit conditionally
150. Debug Locations in our Example Code
59
define i32 @foo(i32 %0, i32 %1) {
%3 = icmp eq i32 %1, 0
%4 = select i1 %3, i32 0, i32 %0
%5 = add nsw i32 %4, %1
ret i32 %5
}
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
line 6 will only hit conditionally
“Don’t create misleading debug locations
that are only correct in some cases”
151. Debug Locations in our Example Code
59
define i32 @foo(i32 %0, i32 %1) {
%3 = icmp eq i32 %1, 0
%4 = select i1 %3, i32 0, i32 %0
%5 = add nsw i32 %4, %1
ret i32 %5
}
struct Point { int x, y; };
int foo(int k, int c) {
struct Point point = {x: 0, y: 0};
if (c) {
point.x = k;
point.y = c;
}
return point.x + point.y;
}
1
2
3
4
5
6
7
8
9
10
line 6 will only hit conditionally
“Don’t create misleading debug locations
that are only correct in some cases”
Delete
152. Preserving Debug Locations in LLVM
60
Prantl and Kumar, US LLVM Dev Meeting 2020
Guidelines for updating debug locations in code transformations
https://tinyurl.com/llvmdebuginfo
Full write-up:
154. Preserving Debug Info in LLVM: Automatically
61
• Common transformation APIs will help you to keep / merge debug
location underlying
155. Preserving Debug Info in LLVM: Automatically
61
• Common transformation APIs will help you to keep / merge debug
location underlying
• e.g. Replace All Uses With (RAUW)
156. Preserving Debug Info in LLVM: Automatically
61
• Common transformation APIs will help you to keep / merge debug
location underlying
• e.g. Replace All Uses With (RAUW)
• Handy debug info utilities to make debug info manipulations easier
157. Preserving Debug Info in LLVM: Automatically
61
• Common transformation APIs will help you to keep / merge debug
location underlying
• e.g. Replace All Uses With (RAUW)
• Handy debug info utilities to make debug info manipulations easier
• salvageDebugInfo helps you to generate llvm.dbg.value intrinsics
158. Preserving Debug Info in LLVM: Automatically
61
• Common transformation APIs will help you to keep / merge debug
location underlying
• e.g. Replace All Uses With (RAUW)
• Handy debug info utilities to make debug info manipulations easier
• salvageDebugInfo helps you to generate llvm.dbg.value intrinsics
• Instruction::applyMergedLocation helps you to merge debug
locations
160. Summary
• We learned how line source locations (e.g. line number) and variable
locations are represented in debug info
62
161. Summary
• We learned how line source locations (e.g. line number) and variable
locations are represented in debug info
• We learned how debug info is stored in LLVM IR
62
162. Summary
• We learned how line source locations (e.g. line number) and variable
locations are represented in debug info
• We learned how debug info is stored in LLVM IR
• The challenges of debug info in optimized binaries, and how LLVM
mitigates those issues
62
166. llvm-dva
• LLVM DVA is still in the process of upstreaming to LLVM
• RFC: https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-
information-visual-analyzer/62570
• You can, however, build it with this patch: https://reviews.llvm.org/D88661
• The llvm-dva command I used in this slides:
• llvm-dva --attribute=location,format --output-sort=offset —
print=symbols,lines,instructions,scopes <object file>
66
173. Splitting Debug Info
• Saving disk spaces
• E.g. Able to de-duplicate type information
69
174. Splitting Debug Info
• Saving disk spaces
• E.g. Able to de-duplicate type information
• Attaching debug info
fi
les (e.g. *.dwo) on release binaries
• E.g. When debugging crashes reported by users
69
175. Splitting Debug Info
• Saving disk spaces
• E.g. Able to de-duplicate type information
• Attaching debug info
fi
les (e.g. *.dwo) on release binaries
• E.g. When debugging crashes reported by users
• Apple platforms are doing this by default (i.e. *.dSYM folders)
69
176. 70
{Struct} 'Point'
{Member} public 'x' -> 'int'
{Location}
{Entry} offset 0
{Member} public 'y' -> 'int'
{Location}
{Entry} offset 4
{Function} extern not_inlined 'foo' -> 'int'
{Variable} 'point' -> 'Point'
{Location}
{Entry} fbreg -24
llvm-dva output DWARF dump