git

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

d-saoc-2021-02.md (4639B)


      1 ---
      2 title: 'SAOC LLDB D integration: 2nd Weekly Update'
      3 date: '2021-10-01T00:05:00+01:00'
      4 tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging']
      5 description: "This post describes what I've done on the 2nd week of the
      6 Symmetry Autumn of Code 2021, including restructuring the libiberty port to be
      7 more C++-like, explains briefly the sent patches to the LLVM upstream review
      8 platform, enumerates the reflected changes pushed to the GCC patches mailing
      9 list and disclose more information about the security issues found on the GCC
     10 codebase."
     11 ---
     12 
     13 Hi D community!
     14 
     15 Sorry for being late this week.
     16 
     17 I'm here again, to describe what I've done during the second week of Symmetry
     18 Autumn of Code.
     19 
     20 ## Finalizing the LLDB integration
     21 
     22 Last week some missing pieces on the test suite and on the LLDB side was
     23 concluded at the beginning of this week and put everything together.
     24 
     25 ## Restructure the code to be more C++ish
     26 
     27 After successfully integrating `libiberty` D demangler into LLVM and before
     28 sending the patches to LLVM, code style needed to be properly handled to
     29 conform with `clang-format` style of LLVM, so, I decided to transform the code
     30 to be more C++ like:
     31 
     32 - Move functions with `struct dlang_info` context to a struct making them
     33   member functions to implicitly pass the context
     34 - Make string handling on the demangler a bit more C++ish (class OutputString)
     35 - Fix structural codestyle to conform with clang formatting such as variables
     36   names, spaces between identifiers, etc...
     37 
     38 I also ended up writing documentation for everything inside the string and
     39 demangler struct for future understanding.
     40 
     41 ## Send patches to the LLVM review platform
     42 
     43 Right after having the codestyle finished, I submitted the patches into the
     44 LLVM review platform. In the meantime, I'm striving for acceptance and
     45 proactively changing the patches to accomplish with the LLVM maintainers
     46 requests.
     47 
     48 The first patch introduces the demangler codebase with the ported code,
     49 available [here](https://reviews.llvm.org/D110578). The second patch enables
     50 support for `llvm-cxxfilt` tool, similar to `c++filt` from GNU binutils,
     51 available [here](https://reviews.llvm.org/D110576). Finally, the last patch
     52 enables the most important part for the users, the LLDB part. The patch is
     53 available [here](https://reviews.llvm.org/D110577).
     54 
     55 ## Reflected GCC changes
     56 
     57 Meanwhile, I found some things to improve on the `libiberty` side that I
     58 changed on my patches to LLVM:
     59 
     60 - Use appendc for single chars append:
     61   [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580512.html).
     62 - Remove parenthesis where it is not needed:
     63   [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580525.html).
     64 - Rename function symbols to be more consistent:
     65   [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580542.html).
     66 - Use switch instead of if-else:
     67   [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580545.html).
     68 
     69 I also made this patch which fixes the testsuite that I previously broke on the
     70 security patches.
     71 
     72 - Add missing format on d-demangle-expected:
     73   [patch](https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580544.html).
     74 
     75 ## About the security issues
     76 
     77 I made a thread on the GCC mailing list to encourage more fuzzing. Currently
     78 the demangler is being fuzzed without any heuristics which makes it inefficient
     79 to search for real security vulnerabilities. Instead, AFL and libfuzzer should
     80 be taken to consideration. My idea is to also add support for GCC/libiberty to
     81 OSS Fuzz. You can check the thread
     82 [here](https://gcc.gnu.org/pipermail/gcc/2021-September/237442.html) and
     83 participate if you have any questions or suggestions on that topic.
     84 
     85 About the exponential time complexity issue, I don't have any news, since I
     86 still don't have the full picture of it. I'm probably not going to dedicate
     87 much time to that since it's kinda out of the scope of this project. Although,
     88 if anyone wants to have a look and discuss hints and suggestions to improve the
     89 current demangler, I appreciate it.
     90 [Here](../../public/assets/posts/d-saoc-2021-02/fuzzer-results/)
     91 are the blobs generated by the fuzzer for timeout and slow-unit triggers.
     92 
     93 ## What's next?
     94 
     95 For now, I'm going to proactively fix the requested changes in the LLVM
     96 patches. They seem to require smaller patches and probably the next week will
     97 be dedicated to that.
     98 
     99 You can also read this on the D programming language forum,
    100 [here](https://forum.dlang.org/thread/mailman.556.1633047753.21945.digitalmars-d@puremagic.com),
    101 and discuss there.
    102 
    103 Read about the [previous week](../d-saoc-2021-01/) and [next
    104 week](../d-saoc-2021-03/).