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
clang-format style of LLVM, so, I decided to transform the code
to be more C++ like:
- Move functions with
struct dlang_infocontext 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
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
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.
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.