| commit | 74a012ed756f5280c71e281c0fd2dd50f83f38b7 | [log] [tgz] |
|---|---|---|
| author | Pavel Labath <pavel@labath.sk> | Tue Jun 10 19:50:33 2025 +0200 |
| committer | GitHub <noreply@github.com> | Tue Jun 10 19:50:33 2025 +0200 |
| tree | 619e8e82f2de31b1e6bc842661b6dcbf83109ae6 | |
| parent | 07a1d479cc4e2d529b04cecb2f97ff16f32ef197 [diff] |
[lldb/aarch64] Fix PC register info augmentation (#143499) This fixes a regression caused by #139817, where we would fail to unwind (using eh_frame) when using debug stubs (like qemu) which do not provide eh_frame register numbers. Unwinding fails because the unwinder tries to convert pc register number to the "eh_frame" scheme (and fails). Previously that worked because the code used a slightly different pattern which ended up comparing the number by converting it to the "generic" scheme (which we do provide). I don't think that's a bug in the unwinder -- we just need to make sure we provide the register number all the time. The associated test is not particularly useful, but I'm hoping it could be used to test other changes like this as well. Other register augmentation changes are tested in an end-to-end fashion (by injecting gdb-remote packets and then trying to read registers). That works well for testing the addition of subregisters, but it isn't particularly suitable for testing register numbers, as the only place (that I know of) where this manifests is during unwinding, and recreating an unwindable process in a test like this is fairly challenging. Probably the best way to ensure coverage for this scenario would be to have lldb-server stop sending eh_frame register numbers (align it with other gdb-like stubs).
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.