My personal website source code
Log | Files | Refs | Submodules | README | LICENSE (5396B)

      1 ---
      2 title: 'SAOC LLDB D integration: 17th Weekly Update'
      3 date: '2022-01-14T20:49:00+01:00'
      4 tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf']
      5 description: "This post describes what I've done on the 17th week of the
      6 Symmetry Autumn of Code 2021, including upstream patches update on the D
      7 demangler and start implementation of support for derived types and more
      8 decoupling on the Clang DWARF parser."
      9 ---
     11 Hi D community!
     13 Sorry for being late. I'm here again, to describe what I've done during the
     14 seventeenth week of Symmetry Autumn of Code.
     16 ## LLVM upstream updates
     18 This week I finished working on the three patches I was working about
     19 demangling and finally merged them in the LLVM upstream:
     21 -
     22 -
     23 -
     25 I also added another trivial patch to pass values by reference instead of a
     26 pointer, requested by dblaikie:
     28 -
     30 ### Bug on LLVM + Clang 13
     32 Before merging, I always run the sanitizer on the whole test suite and the
     33 fuzzer I integrated, although I found a regression on recent LLVM + Clang
     34 builds with the sanitizer arguments. You can read more about the issue in
     35 [this]( patch. Briefly, the problem was that
     36 LLVM is compiled with `-fPIC -fno-semantic-interposition` on LLVM + Clang
     37 13.0.0, although, when combined with `-fsanitize` flags, the generated binary
     38 has incorrect PC-relative relocation information on the generated calls making
     39 it fails on linking. Thanks to [MaskRay](
     40 by helping me diving into this and fixing the problem!
     42 I got surprised by the fact that this was not caught by the buildbots. When
     43 comparing the LLVM released binaries and Arch Linux binaries the problem was
     44 not reproducible. Probably the patched version Arch Linux distributes had
     45 something to do with it but I didn't get a clear answer. This makes some sense
     46 since Arch Linux compiles with SSP (strong stack protection) by default and
     47 that adds extra calls that, when compiled with `-fPIC` seem to be also
     48 PC-relative.
     50 That regression made me creating two more trivial patches:
     52 -
     53 -
     55 ## Extending dumping for derived types
     57 I started tinkering with derived types, more specifically with `alias`. The
     58 same with built-in types the logic can be extended to other derived types
     59 as well. In DWARF `DW_TAG_typedef_type` is generated whenever a variable is
     60 typed with an `alias`. I did some basic logic to make it work, although I need
     61 to do some decoupling from Clang due to type forwarding.
     63 I still need to understand how types are forwarded in DWARF, because the types
     64 are read sequentially and a `DW_TAG_typedef_type` can reference an address "in
     65 the future" that points to a `DW_TAG_base_type` which need to be resolved
     66 later. I tried to search how Go plugin did that ([see
     67 diff](
     68 but `dwarf->ResolveTypeUID` got removed.
     70 You can consult the source code
     71 [here](
     73 ## More decoupling on the Clang DWARF Parser
     75 I was about to decouple `GetContainingClangModuleDIE` and
     76 `GetContainingClangModule` functions, although, my test suite is not running
     77 correctly. LLDB test suite is a nightmare to me and I'm trying to push forward
     78 on more clarity about which tests are marked as Unsupported or Expected to
     79 Fail. I always had this problem since I started working on the LLDB tree
     80 although I took the risk of ignoring them. I couldn't contact `lldb-dev` since
     81 there is some restrictions on the mailing list due to spam and I got not answer
     82 on my subscription request. Finally LLVM moved to
     83 [discourse](, so I created two posts there to
     84 describe my problems:
     86 -
     87 -
     89 The first one already got some attention and
     90 [JDevlieghere]( already submitted a
     91 patch. I had no idea that the buildbot infrastructure was open source. I
     92 already have some patches to submit about this topic, including activating Lua
     93 tests, which is failing locally and not tested on the buildbots.
     95 ## What is next?
     97 Well, I plan to continue working on the custom DWARF Parser for D, including
     98 adding support for other basic stuff like functions. Even though this is the
     99 last weekly update, I'm going to try to keep up with some changes on the LLVM
    100 tree. My goal is to have some minimum support (roughly the same of GDB) on
    101 LLDB 14. I will try to submit the bare minimum support which need to include
    102 some workarounds on the Clang DWARF Parser. This may not be accepted due to
    103 that, but if it does, we can have custom formatters officially on LLDB. I will
    104 try to provide soon some builds for the community of
    105 [this]( branch,
    106 although.
    108 You can also read this on the D programming language forum,
    109 [here]([email protected]),
    110 and discuss there!
    112 Read about the [previous week](../d-saoc-2021-16/).