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.
-
Fixing the parsing of metadata from ELF.
- Because LLDB has the executable's on-disk data, the approach I took was reading the information used to finding the reflection sections from the on-disk file and using this information to map the sections in the running process.
- Tests enabled: 40 different tests were enabled, out of which 7 were previously expected failures, and 33 were skipped.
- Pull Requests:
- Fix reading metadata from ELF sections by augusto2112 · Pull Request #33321 · apple/swift · GitHub
- Add functionality that returns correct reflection section name for different object files (Mach-O, ELF, COFF) by augusto2112 · Pull Request #33358 · apple/swift · GitHub
- Fix reading elf section from file buffer by augusto2112 · Pull Request #33434 · apple/swift · GitHub
- Use new libReflection API when reading ELF files by augusto2112 · Pull Request #1608 · apple/llvm-project · GitHub
- Enable Linux passing tests by augusto2112 · Pull Request #1657 · apple/llvm-project · GitHub
- Enables tests passing after fix of parsing elf object files by augusto2112 · Pull Request #1668 · apple/llvm-project · GitHub
-
Adapting SwiftReflectionTest to work on Linux.
- The approach used was adding entry points in the Swift runtime that returns the reflection information necessary for the reflection tests, instead of parsing the metadata from the process. It was also necessary to fix bugs related to interpreting metadata information on platforms that lack Objective-C support.
- Tests enabled: 42 different tests were enabled, which were previously disabled on Linux .
- Pull Requests:
- https://github.com/apple/swift/pull/32339
- Unify COFF and ELF data structures and procedures by augusto2112 · Pull Request #32478 · apple/swift · GitHub
- Move 'MetadataSections' from 'ImageInspectionElf.h' to SwiftShims by augusto2112 · Pull Request #32493 · apple/swift · GitHub
- Enable validation reflection tests passing on Linux by augusto2112 · Pull Request #33134 · apple/swift · GitHub
- Conditionalize 'num_extra_inhabitants' in 64 bit platforms's tests by augusto2112 · Pull Request #33136 · apple/swift · GitHub
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:
- Fix of loading of scalars as addresses.
- Loading of scalars were mistakenly interpreted as addresses in the context of the entity variable's materializer, which caused problems when materializing a variable from a register.
- Tests enabled: one test, marked as an expected failure, was enabled in Linux.
- Pull Requests:
- Disable loading scalars as addresses when materializing an entity variable by augusto2112 · Pull Request #1452 · apple/llvm-project · GitHub
- Disable loading scalars as addresses when materializing an entity variable (swift/release/5.3) by augusto2112 · Pull Request #1454 · apple/llvm-project · GitHub
- Remove bypass of GetAddressOf when dealing with dynamic class types in variable materialization by augusto2112 · Pull Request #1455 · apple/llvm-project · GitHub
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!