Google Summer of Code "Improving Swift’s Debugger experience on Linux" Final Report

GSOC has come to an end. In this post, I'll summarize the work done in the summer, as well as the overall experience of contributing to the Swift project. Hopefully, this will useful for future GSOC participants as well.

As a multi-platform language, offering the best possible experience for users is in the Swift project's interests. With Swift on the server and Swift for Tensorflow, the importance of maintaining good tools outside macOS only grows. My main focus during the summer was improving LLDB for Linux, in order to offer a better debugging experience on the platform. In a nutshell, my major accomplishment during the summer is enabling LLDB/Swift to access metadata stored in ELF files which were previously inaccessible from Linux.

The problem: Swift places metadata information in sections. ELF's (the file format used for linking and execution on Linux) philosophy is that sections are used for linking, and segments in execution. Although sections exist during execution, the information used to locate a specific section does not, as it is theoretically not needed anymore, and is stripped from the running process. I was able to solve this issue for swift reflections tests as well as LLDB, but different approaches were used due to different constraints.

As a future task, it would be ideal if we found a way to locate the section information exclusively from a running process, as this would make it more similar to how this process behaves on macOS and Windows.

Besides those major tasks, I also fixed an unrelated LLDB bug:

Looking back, I think that this Summer of Code was, overall, a success. Now, I'd like to share my experience as a participant in GSOC.

Contributing to the Swift project was very challenging, and initially quite a daunting task: an industrial-grade debugger/compiler is an extremely complex project; coupled with the fact that iteration cycles can take very long (it was common for me to wait a couple of hours for the macOS-specific tests to run on the CI, only for it to fail because of some very silly oversight on my part) made it very apparent that my usual debugging work-flow (where I started with the debugger, then understood the problem, then found the solution) would not be suitable in this case. I learned how to examine the code in a lot more detail, try to understand all the parts involved (making use of the many logging tools in Swift/LLDB) that might be causing a bug, before actually running the debugger, or implementing a half thought out solution and see if they would work (it never did!). I think this alone made it well worth it for me in participating in GSOC, and I believe the skills gained here will be very useful in whatever I work on in the future. As a side-note, understanding (even if from a very superficial level) all the different steps a debugger goes through in evaluating a simple expression, was, at the same time, staggering and fascinating. This made me a lot more appreciative of the work put in by so many people so we, as developers, can have a better user experience.

Another very interesting aspect of contributing to an open-source project is the interaction with other members of the community. Although I was aware of the importance of communication beforehand, I believe I still underestimated the difficulty involved in communicating with other people in the project. As a participant in GSOC, but, more broadly, as a newcomer developer, it was especially tricky to find the right balance between figuring things out alone and asking for help: at the same time I wanted to solve my tasks, I didn't want to disrupt other people with what I thought were silly questions. I believe this is where my biggest failure was: in the beginning, I was unwilling to ask for help in most situations, which caused a lot of time I could've used to solve more issues to be wasted. In retrospect, I think the best solutions would've been scheduling a recurring chat with my mentors every week (even if only for 15 minutes) would've been a lot better for my productivity. Nevertheless, I was honestly very surprised with members of the project's willingness to help, I'm very grateful for everyone that took the time to help me. In regards to my mentors, I have nothing but good things to say about them, they would always promptly answer any questions I had and were always willing to schedule pair-programming sessions me whenever I asked.

As a minor feedback point for future GSOCs, I'd like to suggest adding an extra membership-level on Github which allows users to trigger CI tests but not merge anything. I believe this would be beneficial to everyone involved: for mentors, they would not be interrupted in whatever they were working on just to run CI tests; for mentees, this would allow for shorter feedback loops, as well as making it possible for them to continue work even if the mentor is not available (for example, during weekends).

Finally, I'd like to thank my mentors (@vedantk and @Adrian_Prantl ). They were awesome, I really couldn't have asked for more patient or qualified people. I'd like to thank other members of the community as well (@compnerd , @Mike_Ash , @Joe_Groff , @Michael_Gottesman , among others) I'm very happy I could learn from your expertise, and thank you for your patience. I'm truly grateful for being able to participate in GSOC, and plan to continue contributing to the Swift project in the future!


Thanks @augusto2112 for all your hard work! You tackled a very complex problem and made a real difference for all Linux Swift developers. To emphasize the impact: Before Augusto's improvements it was not possible to display any variables that needed access to to runtime type metadata on Linux at all. That made debugging most "interesting" Swift code very difficult.

I also appreciate the thoughtful feedback on our process and I hope we can use it to make our development process friendlier and less cumbersome in the future.

Again, thanks — this was really meaningful work.

Terms of Service

Privacy Policy

Cookie Policy