Hi D community!

Sorry for being late this week.

I’m here again, to describe what I’ve done during the second week of Symmetry Autumn of Code.

Finalizing the LLDB integration

Last week some missing pieces on the test suite and on the LLDB side was concluded at the beginning of this week and put everything together.

Restructure the code to be more C++ish

After successfully integrating libiberty D demangler into LLVM and before sending the patches to LLVM, code style needed to be properly handled to conform with clang-format style of LLVM, so, I decided to transform the code to be more C++ like:

  • Move functions with struct dlang_info context to a struct making them member functions to implicitly pass the context
  • Make string handling on the demangler a bit more C++ish (class OutputString)
  • Fix structural codestyle to conform with clang formatting such as variables names, spaces between identifiers, etc…

I also ended up writing documentation for everything inside the string and demangler struct for future understanding.

Send patches to the LLVM review platform

Right after having the codestyle finished, I submitted the patches into the LLVM review platform. In the meantime, I’m striving for acceptance and proactively changing the patches to accomplish with the LLVM maintainers requests.

The first patch introduces the demangler codebase with the ported code, available here. The second patch enables support for llvm-cxxfilt tool, similar to c++filt from GNU binutils, available here. Finally, the last patch enables the most important part for the users, the LLDB part. The patch is available here.

Reflected GCC changes

Meanwhile, I found some things to improve on the libiberty side that I changed on my patches to LLVM:

  • Use appendc for single chars append: patch.
  • Remove parenthesis where it is not needed: patch.
  • Rename function symbols to be more consistent: patch.
  • Use switch instead of if-else: patch.

I also made this patch which fixes the testsuite that I previously broke on the security patches.

  • Add missing format on d-demangle-expected: patch.

About the security issues

I made a thread on the GCC mailing list to encourage more fuzzing. Currently the demangler is being fuzzed without any heuristics which makes it inefficient to search for real security vulnerabilities. Instead, AFL and libfuzzer should be taken to consideration. My idea is to also add support for GCC/libiberty to OSS Fuzz. You can check the thread here and participate if you have any questions or suggestions on that topic.

About the exponential time complexity issue, I don’t have any news, since I still don’t have the full picture of it. I’m probably not going to dedicate much time to that since it’s kinda out of the scope of this project. Although, if anyone wants to have a look and discuss hints and suggestions to improve the current demangler, I appreciate it. Here are the blobs generated by the fuzzer for timeout and slow-unit triggers.

What’s next?

For now, I’m going to proactively fix the requested changes in the LLVM patches. They seem to require smaller patches and probably the next week will be dedicated to that.

You can also read this on the D programming language forum, here, and discuss there.

Read about the previous week and next week.