git

commit c1a81e32b69aee3d1305d973a1d23763714b8d52
parent 41696ed78acd02b2c9cbfed7e454d61b8785ab94
Author: Luís Ferreira <[email protected]>
Date:   Fri,  1 Oct 2021 00:05:57 +0100

posts: add SAOC LLDB D integration: 2nd Weekly Update

Signed-off-by: Luís Ferreira <[email protected]>

Diffstat:
A
content/posts/d-saoc-2021-02.md
 | 
87
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 file changed, 87 insertions(+), 0 deletions(-)
diff --git a/content/posts/d-saoc-2021-02.md b/content/posts/d-saoc-2021-02.md
@@ -0,0 +1,87 @@
+# SAOC LLDB D integration: 2nd Weekly Update
+
+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](https://reviews.llvm.org/D110578). The second patch enables
+support for `llvm-cxxfilt` tool, similar to `c++filt` from GNU binutils,
+available [here](https://reviews.llvm.org/D110576). Finally, the last patch
+enables the most important part for the users, the LLDB part. The patch is
+available [here](https://reviews.llvm.org/D110577).
+
+## 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](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580512.html).
+- Remove parenthesis where it is not needed:
+  [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580525.html).
+- Rename function symbols to be more consistent:
+  [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580542.html).
+- Use switch instead of if-else:
+  [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580545.html).
+
+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](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580544.html).
+
+## 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](https://gcc.gnu.org/pipermail/gcc/2021-September/237442.html) 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](http://ipfs.io/ipfs/bafybeihw6bk46r7gnkp6estkwk7ucilxb2swlwzzi2izpytaclypxeu2wq/)
+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.