Some notes on porting Delve to PPC64LE

Delve is a debugger for Go programs that currently supports multiple architectures and operating systems. At the time of this writing, Delve supports Linux on x86_64, aarch64, and 386, Windows on x86_64, and macOS on x86_64. These are the most common architectures that Go supports. But the list of potential architectures is long, and on that list is PPC64LE, an architecture that a significant amount of users use on servers. PPC64LE is the code name for the little endian mode of the Power ISA, introduced by Power8 around 2013. You can run Linux operating systems such as Red Hat Enterprise Linux (RHEL) or Fedora on this architecture.

While working on a bug that targeted RHEL on PPC64LE, I realized that I needed a debugger and the options were limited. You can use GDB, which runs flawlessly on PPC64LE and understands Go binaries, but it needs to understand Go programs better. Delve does a better job of understanding the runtime and data structures. But Delve doesn't support PPC64LE at that point. So I asked myself: How hard could it be to port Delve to PPC64LE? As you might have guessed, this is my first port ever.

Porting is hard

By porting, people usually refer to adapting something existing to a different scenario. It can be to another operating system, CPU architecture, library, etc.

When porting a piece of software to a different CPU architecture, as in our case, if the compiler and the libraries support the targeted architecture, there is little work to do. Most things would work out of the box. But a debugger like Delve needs to intercept system calls and understand CPU registers, among other things, so even though Go supports PPC64LE, the amount of work necessary can be considerable.

Documentation

As in any other project, the first step is to gather documentation. And for these kinds of projects, the first things to check are the official specifications and other projects that already support the architecture.

Most of the Power documentation can be found on the OpenPower Foundation web page. In particular, the most meaningful documents are the ELF ABI specification and the Power ISA books. Beware that these are lengthy documents. Apart from these documents, the DWARF documentation is a must-have.

As a side note, I can't recommend Zotero enough if you struggle with documentation organization. Give it a try.

Finding other projects that already implement the architecture always helps. In this case, the way in which Go, LLVM, and GDB handle registers was quite instructive. Checking the Linux kernel code also helped in multiple situations. For these kinds of scenarios, nothing beats checking similar projects' source code repositories. As a pro tip: Always use the control version repository advance search to filter out irrelevant files.

Another thing you can do is check other ports in the same project. Even if they're not on the same architecture, checking how other ports were done is vital to understand what you need to do.

Testing

To test your code, you will need a laboratory. For PPC64LE, there are different routes that we can follow. The easiest and the most comfortable to use is an SSH connection to a machine. Some folks prefer to work directly in the lab, while others like to work on their local devices and copy the code to the lab. I'm currently doing the latter, but if you want to do the former, be sure to save your work constantly. You want to maintain your changes in a safe place when refreshing the lab to a clean state. For those who wish to follow my work-local/run-remotely approach, rsync and inotify are your friends. I detected changes with inotify and synced everything to the remote laboratory.

If you don't have access to a device, check Linux distributions. Some of them might give you access to shared virtual or real servers where you can test the code if you are part of the projects and the work you plan to do is relevant to them.

Another route is to use virtual laboratories. If you choose this path, remember that the performance might be worse than using a server. On the other hand, the cost is almost zero. For PPC64LE, the best approach is to use QEMU or the official IBM Power simulator. Both work flawlessly. I started the port with QEMU, but I eventually moved to a server because the emulation was really slow on my machine.

Debugging a debugger

Luckily, Delve has an impressive test suite. That gives me a privileged starting point: Every single test must pass.

As simple as it sounds, sometimes things can get messy. How do you debug a debugger when you don't have a debugger? Well, I have three tools:

• print("HERE!"): This is the most common line I have written. Printing variable values, memory states, and complex structures immensely helped me. It might not be fancy, but it sure is effective.

• panic("NOT IMPLEMENTED"): Sometimes, you need to implement methods and functions that you don't understand yet to compile your code. Instead of only adding a TODO comment, also add a panic. Make your code fail. Later, when a piece of code you are trying to make work suddenly panics, you can quickly jump into the offending piece of code.

• Pen and paper: This is probably the trickiest of all. Using the previous two tools allows you to follow the execution of the code and print where things break. Still, it would be best if you had a way to visualize the calls to keep you focused and not overwhelmed by the issue's complexity. Sketching diagrams, writing function names, and keeping a list of questions to yourself or others who might know more than you help put thoughts in the proper place. Usually, this helps in understanding the issue. Don't underestimate the power of the paper!

Conclusion

What is the current state of the whole port? It's almost done! There are a few tests left —four at the time of this writing— that I need to fix, and once they're resolved I will be able to submit the work upstream. Hopefully, this will happen soon.

As you can see, porting is intricate and takes time. But the results are well worth it. Users of PPC64LE will be able to debug complex scenarios with a familiar tool and spend less time fixing bugs. And to be honest, it is an exciting project to work on!