1 --- 2 title: 'SAOC LLDB D integration: 14th Weekly Update' 3 date: '2021-12-23T19:18:00+01:00' 4 tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf'] 5 description: "This post describes what I've done on the 14th week of the 6 Symmetry Autumn of Code 2021, including milestone 4 tasks list, some patches on 7 the upstream about unicode char support, add support for type name dumping and 8 implementation of LLDB helpers for DType wrapper." 9 --- 10 11 Hi D community! 12 13 I'm here again, to describe what I've done during the fourteenth week of 14 Symmetry Autumn of Code. Updates on my COVID situation: I successfully 15 recovered from it, just feel some tiredness and lack of energy sometimes, but 16 other than that, dry cough is now occasional and I already recovered from the 17 other symptoms such as lack of smell and taste, and fever. Nothing to worry, 18 from now on :) 19 20 ## Milestone 4 rough task list 21 22 Since the route of the project changed a bit and I had no concrete plans for 23 the 4th milestone on my previous milestone list, I wrote some rough list of 24 tasks to tick off during development. This list can be quite extensive, since 25 there is a lot to integrate with LLDB. The general idea would be to adapt Clang 26 logic and decouple it as much as possible to make that logic more language 27 agnostic and therefore fit D or other future languages: 28 29 - **Implement DWARF basic type parsing and integration with the TypeSystem:** 30 To implement this, it is required to support the majority of the basic types 31 not including type modifiers (only DWARF base type, `DW_TAG_base_type`). It 32 is required to have a map between DType wrapper and the following LLDB 33 enumerations: 34 35 * `lldb::Format` 36 * `lldb::Encoding` 37 * `lldb::BasicType` 38 39 It is also required to have some knowledge of the bit size of each basic 40 type. Other built-in types like vectors may be skipped, if complicated to 41 integrate at this stage. 42 43 This enumeration mapping is responsible of formatting the output value with 44 the right encoding, according to a certain type. From what I'm aware of and 45 according to my knowledge on the LLVM infrastructure, this is the only thing 46 required to get value dumping done, but some additional step may be required, 47 in practice. I still need to understand a bit more what `Dump`, `DumpValue`, 48 `DumpSummary` and other dump related methods are for. 49 50 After this, the next step is to support other types such as: 51 52 - **Support type modifiers:** To fully support types it is required to read 53 other considered type modifiers such as pointers, _typedefs_ (aliases) and 54 types associated with a type qualifier such as const, immutable, ... 55 56 - **Support aggregate types:** Aggregate types such as structs, unions or 57 classes need to be supported. Only simple support is desired, since stuff 58 like inheritance can be a bit more complicated to handle. At least struct 59 fields or base class members may be simple enough. 60 61 - **Support arrays:** Not to be confused with D slices, which are technically 62 interpreted as structs. D slices can be later recognized as native dynamic 63 arrays, but synthetic formatters can handle it for now (work done on the 64 Milestone 2). The idea here, at this stage, would be to support static 65 stack allocated arrays. 66 67 - **Support other types:** Other types like enumerations can be supported. 68 69 - **Implement DWARF function parsing and integration with the TypeSystem:** To 70 implement this, it is required to support 71 `DW_TAG_subprogram`/`DW_TAG_subroutine_type` tags which is dependent of a 72 special type for functions called subroutine types. Support D linkage is 73 blocked due to inconsistent calling convention on both DMD/LDC 74 implementations (see my attempt to fix it 75 [here](https://github.com/dlang/dmd/pull/13287)), so C linkage should be a 76 simple way to support it or rely on GDC implementation. 77 78 After having support for this special type, we should implement the 79 `ParseFunctionFromDWARF` DWARFASTParser override, which is responsible of 80 parsing all the function child tags, such as formal parameters including 81 normal parameters and variadic parameters, and inner functions (functions 82 with the context of the parent outer function). 83 84 I haven't explored much about function features on LLDB, so there might be 85 some hidden dependency I don't know about. 86 87 88 ## LLVM upstream updates 89 90 During the development of DType mapping to lldb::BasicType, I found out that 91 UTF-8 char basic type was missing, so I wrote two patches to implement it on 92 the upstream: 93 94 - https://reviews.llvm.org/D116136 95 - https://reviews.llvm.org/D116138 96 97 With that in mind, I also got the missing part to make unicode8 formatting 98 working on Clang-based TypeSystem, completing the D language plugin as well. 99 I've done a partial patch to fix that in the past 100 ([D112564](https://reviews.llvm.org/D112564)), so I amended it and added the 101 requested tests to be ready to merge. 102 103 ## Helpers in DType wrapper for LLDB enumerations 104 105 I implemented some helpers required in the DType wrapper to make the type kind 106 with: 107 108 * `lldb::Format` 109 * `lldb::Encoding` 110 * `lldb::BasicType` 111 112 With that done, I started tinkering with LLDB dumping system, although, some 113 unknown dependency is still missing (`Dump` functions are not being called with 114 those helpers implemented). My guess is that some missing type information is 115 required in order to LLDB recognize a type as, e.g. scalar type. 116 117 ## Type name dumping 118 119 Value dumping is not yet working, but I already got a way to dump the type 120 name. For now it is only dumping type name for `bool`. The output looks 121 something like this: 122 123 ``` 124 (lldb) ta v 125 Global variables for app.d in app: 126 (bool) app.bar = <No TLS data currently exists for this thread.> 127 128 app.ptr = <could not resolve type> 129 (bool) app.foobar = 130 ``` 131 132 You can consult the source code for those changes 133 [here](https://github.com/devtty63/llvm-project/tree/lldb-d/implement-typesystem-d). 134 135 ## What is next? 136 137 I plan to extend type name dumping to the rest of the built-in type kinds by 138 mapping constant names to the kind enumeration. I also plan to hopefully have 139 some output about `app.foobar` value. For that, I'm going to investigate the 140 missing dependency and implement the missing logic. If that is successful, I 141 will extend it to the rest of the built-in types. 142 143 You can also read this on the D programming language forum, 144 [here](https://firstname.lastname@example.org#post-ynyjkvhgetyubpaffzxu:40forum.dlang.org), 145 and discuss there! 146 147 Read about the [previous week](../d-saoc-2021-13/) and the [next 148 week](../d-saoc-2021-15/).