d-saoc-2021-17.md (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 --- 10 11 Hi D community! 12 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. 15 16 ## LLVM upstream updates 17 18 This week I finished working on the three patches I was working about 19 demangling and finally merged them in the LLVM upstream: 20 21 - https://reviews.llvm.org/D111416 22 - https://reviews.llvm.org/D111417 23 - https://reviews.llvm.org/D111419 24 25 I also added another trivial patch to pass values by reference instead of a 26 pointer, requested by dblaikie: 27 28 - https://reviews.llvm.org/D117046 29 30 ### Bug on LLVM + Clang 13 31 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](https://reviews.llvm.org/D102453) 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](https://reviews.llvm.org/p/MaskRay/) 40 by helping me diving into this and fixing the problem! 41 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. 49 50 That regression made me creating two more trivial patches: 51 52 - https://reviews.llvm.org/D117144 53 - https://reviews.llvm.org/D117145 54 55 ## Extending dumping for derived types 56 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. 62 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](https://github.com/llvm/llvm-project/commit/77198bc79b54267f2ce981c3a6c9c0d6384cac01#diff-72ec6c46e57cb00bb94855699a3a5d8d268a73e8ec226404d5f9b175de7d1d19)) 68 but `dwarf->ResolveTypeUID` got removed. 69 70 You can consult the source code 71 [here](https://github.com/devtty63/llvm-project/commits/lldb-d/implement-typesystem-d). 72 73 ## More decoupling on the Clang DWARF Parser 74 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](https://llvm.discourse.group/), so I created two posts there to 84 describe my problems: 85 86 - https://llvm.discourse.group/t/lldb-buildbots-verbosity/5253 87 - https://llvm.discourse.group/t/lldb-test-suite-is-failing-on-linux-x86-64/5696 88 89 The first one already got some attention and 90 [JDevlieghere](https://reviews.llvm.org/p/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. 94 95 ## What is next? 96 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](https://github.com/devtty63/llvm-project/commits/lldb-d/main) branch, 106 although. 107 108 You can also read this on the D programming language forum, 109 [here](https://forum.dlang.org/thread/[email protected]), 110 and discuss there! 111 112 Read about the [previous week](../d-saoc-2021-16/).