Introduction

LLVM Passes are an extraordinarily powerful tool that allow us to hook our own logic into the LLVM compilation process - by leveraging an extensive API that works on LLVM IR, we can run custom passes that belong to one of three categories:

• Analysis
• Transform

or

• Utility

LLVM Passes are similar in spirit to GCC plugins, but with richer documentation and a more fleshed out ecosystem. The LLVM Project invests significant effort in a clean codebase - and the effort shines when developing the passes.

Initial Motivation - Backstory

My initial interest in LLVM Passes began in a previous project I worked on - I was compiling code and running it in a system with:

• Full fledged networking capabilities, i.e.
  • The ability to open sockets, accept connections, open connections
• No built-in debugging facilities
  • No ability to remotely attach to the running code
  • No OS primitives to allow for implementing GDB’s Remote Serial Protocol (i.e. no ability to implement a functional gdbserver alternative)
  • Limited tracing capabilities

I often found myself frustrated that even though I was able to establish full network communications with the system, I was unable to properly debug my code beyond black-boxing and the limited tracing capabilities afforded to me. I found myself thinking something along the lines of:

<aside> 💡 What if every single opcode was augmented with a network protocol that would communicate with a debugging host?

</aside>

What this means is - for every single opcode - we would have code that would send a packet out to a host to notify it of the current debugging state, and wait for further commands (standard step/ continue / run to)

This is a pretty crazy fucking idea, because:

• We would effectively have full debugging control over the target system - utilizing only standard networking capabilities
• We could leverage this idea to implement GDB’s Remote Serial Protocol and allow for full gdb-based debugging

There are some stark disadvantages that immediately come to mind:

• Performance would take a massive beating - every opcode would suddenly have an overhead of hundreds if not thousands of additional opcodes that would handle the debuggee-debugger communications. In practice the overhead would be ameliorated by the usage of breakpoints - not every opcode would have to go through a full networking session, but the overhead would still be tremendous
• Code size would take a similar beating