git

My personal website source code
Log | Files | Refs | Submodules | README | LICENSE

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:
Acontent/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.