LLVM is once again participating in Google Summer of Code (GSOC). For 2024 we have an exciting project to enrich the disassembler in LLDB. The project consists of using the variable location information from the debug info (DWARF) to annotate LLDB’s disassembler (and register read) output with the location and lifetime of source variables. You can find all the details on LLVM’s Google Summer of Code Ideas & Projects page....

Today Google announced the list of open-source organizations participating in the 2021 Google Summer of Code program. Together with Raphael and Pedro, I’ll be mentoring the following two projects: A structured approach to diagnostics in LLDB Lua scripted watchpoints in LLDB If you’re interested in either of these projects or have questions, feel free to reach out. For more information about GSoC itself check out the Summer of Code website.

To make incremental builds fast on macOS, the static linker (ld) ignores the debug information. It can easily be a magnitude bigger than the rest of the program and slow down link time. Instead the linker emits a debug map which contains the location of all the object files it relocated so that debug info consumers (such as the debugger) know where to find the DWARF debug info. This approach works great during development and greatly speeds up the build-debug cycle....

If you’ve ever used the debugger, chances are you’ve used a file and line number to set a breakpoint. Most of the time this provides enough granularity. Sometimes, though, more fine grained control would be helpful. Consider the following example: 1 int foo() { 2 return 1; 3 } 4 int bar() { 5 return 2; 6 } 7 int baz() { 8 return 3; 9 } 10 int main(int argc, char** argv) { 11 return foo() + bar() + baz(); 12 } Line Breakpoints Let’s say we want to step into the function baz on line 11 and can’t set a breakpoint on baz itself....

LLDB is the debugger developed as part of the LLVM project. It is probably most known as the debugger in Xcode, but many use it as an alternative to GDB. Scripting in LLDB One thing that makes LLDB really powerful is how scriptable it is. It has a stable C++ API, called the SB API or Scripting Bridge API, which is accessible through Python. Following LLVM’s model of reusable components, most of LLDB constitutes a debugger library and the SB API is how tools like the command line driver interface with it....

Python has great interoperability with C and C++ through extension modules. There are many reasons to do this, such as improving performance, accessing APIs not exposed by the language, or interfacing with libraries written in C or C++. Unlike Python however, C and C++ are not memory safe. Luckily, great tools exist to help diagnose these kind of issues. One of those tools is ASan (Address Sanitizer) which uses compiler instrumentation to detect memory errors at runtime....

Recently I wanted to call some C code from Python to check who was sending a particular signal. Apparently this functionality is only available as of Python 3 so I decided to write a custom module. Doing so is relatively easy but all the documentation I found only was usingdistutils to build the module and skipped over how to find the newly builtmodule. This post is mostly a write up of what I found out....

After having used YouCompleteMe, I finally decided to give one of the Language Server Protocol (LSP) implementations a spin. As an LLVM developer I’ve been following clangd’s development and wanted to try it out. At the time of writing, several LSP implementations exist for Vim: LanguageClient-neovim vim-lsc vim-lsp Setting up vim-lsp I decided to go with vim-lsp because it’s asyncronous, written in vimscript and easy to setup. The plugin has a single dependency: async....

Finding the right people to review your patch can be tough. I see the question “who should I add as reviewer for this patch?” popping up on IRC quite regularly and not something I’m unfamiliar with myself. Not every project has a list of code owners and as soon as your change spans multiple components things might get tricky. Preferable you want reviewers that know the code you’ve changed. If the project is using git you can use git blame to find out for each individual line of a file, who changed it last....