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

commit a6863ae5cf5a62323b6d692de37fb31cf7f277ed
parent 0e2a33f5d9747026e437536aa6de090dc034300b
Author: Luís Ferreira <[email protected]>
Date:   Thu, 23 Dec 2021 21:25:39 +0000

posts: Add 'SAOC LLDB D integration: 14th Weekly Update'

Signed-off-by: Luís Ferreira <[email protected]>

Mcontent/posts/ | 3++-
Acontent/posts/ | 143+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 145 insertions(+), 1 deletion(-)

diff --git a/content/posts/ b/content/posts/ @@ -55,4 +55,5 @@ You can also read this on the D programming language forum, [here]([email protected]), and discuss there! -Read about the [previous week](../d-saoc-2021-12/). +Read about the [previous week](../d-saoc-2021-12/) and the [next +week](../d-saoc-2021-14/). diff --git a/content/posts/ b/content/posts/ @@ -0,0 +1,143 @@ +--- +title: 'SAOC LLDB D integration: 14th Weekly Update' +date: '2021-12-23T19:18:00+01:00' +tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf'] +description: "This post describes what I've done on the 14th week of the +Symmetry Autumn of Code 2021, including milestone 4 tasks list, some patches on +the upstream about unicode char support, add support for type name dumping and +implementation of LLDB helpers for DType wrapper." +--- + +Hi D community! + +I'm here again, to describe what I've done during the fourteenth week of +Symmetry Autumn of Code. Updates on my COVID situation: I successfully +recovered from it, just feel some tiredness and lack of energy sometimes, but +other than that, dry cough is now occasional and I already recovered from the +other symptoms such as lack of smell and taste, and fever. Nothing to worry, +from now on :) + +## Milestone 4 rough task list + +Since the route of the project changed a bit and I had no concrete plans for +the 4th milestone on my previous milestone list, I wrote some rough list of +tasks to tick off during development. This list can be quite extensive, since +there is a lot to integrate with LLDB. The general idea would be to adapt Clang +logic and decouple it as much as possible to make that logic more language +agnostic and therefore fit D or other future languages: + +- **Implement DWARF basic type parsing and integration with the TypeSystem:** + To implement this, it is required to support the majority of the basic types + not including type modifiers (only DWARF base type, `DW_TAG_base_type`). It + is required to have a map between DType wrapper and the following LLDB + enumerations: + + * lldb::Format + * lldb::Encoding + * lldb::BasicType + + It is also required to have some knowledge of the bit size of each basic + type. Other built-in types like vectors may be skipped, if complicated to + integrate at this stage. + + This enumeration mapping is responsible of formatting the output value with + the right encoding, according to a certain type. From what I'm aware of and + according to my knowledge on the LLVM infrastructure, this is the only thing + required to get value dumping done, but some additional step may be required, + in practice. I still need to understand a bit more what `Dump`, `DumpValue`, + `DumpSummary` and other dump related methods are for. + + After this, the next step is to support other types such as: + + - **Support type modifiers:** To fully support types it is required to read + other considered type modifiers such as pointers, _typedefs_ (aliases) and + types associated with a type qualifier such as const, immutable, ... + + - **Support aggregate types:** Aggregate types such as structs, unions or + classes need to be supported. Only simple support is desired, since stuff + like inheritance can be a bit more complicated to handle. At least struct + fields or base class members may be simple enough. + + - **Support arrays:** Not to be confused with D slices, which are technically + interpreted as structs. D slices can be later recognized as native dynamic + arrays, but synthetic formatters can handle it for now (work done on the + Milestone 2). The idea here, at this stage, would be to support static + stack allocated arrays. + + - **Support other types:** Other types like enumerations can be supported. + +- **Implement DWARF function parsing and integration with the TypeSystem:** To + implement this, it is required to support + `DW_TAG_subprogram`/`DW_TAG_subroutine_type` tags which is dependent of a + special type for functions called subroutine types. Support D linkage is + blocked due to inconsistent calling convention on both DMD/LDC + implementations (see my attempt to fix it + [here](, so C linkage should be a + simple way to support it or rely on GDC implementation. + + After having support for this special type, we should implement the + `ParseFunctionFromDWARF` DWARFASTParser override, which is responsible of + parsing all the function child tags, such as formal parameters including + normal parameters and variadic parameters, and inner functions (functions + with the context of the parent outer function). + + I haven't explored much about function features on LLDB, so there might be + some hidden dependency I don't know about. + + +## LLVM upstream updates + +During the development of DType mapping to lldb::BasicType, I found out that +UTF-8 char basic type was missing, so I wrote two patches to implement it on +the upstream: + +- +- + +With that in mind, I also got the missing part to make unicode8 formatting +working on Clang-based TypeSystem, completing the D language plugin as well. +I've done a partial patch to fix that in the past +([D112564](, so I amended it and added the +requested tests to be ready to merge. + +## Helpers in DType wrapper for LLDB enumerations + +I implemented some helpers required in the DType wrapper to make the type kind +with: + + * lldb::Format + * lldb::Encoding + * lldb::BasicType + +With that done, I started tinkering with LLDB dumping system, although, some +unknown dependency is still missing (`Dump` functions are not being called with +those helpers implemented). My guess is that some missing type information is +required in order to LLDB recognize a type as, e.g. scalar type. + +## Type name dumping + +Value dumping is not yet working, but I already got a way to dump the type +name. For now it is only dumping type name for `bool`. The output looks +something like this: + +``` +(lldb) ta v +Global variables for app.d in app: +(bool) = <No TLS data currently exists for this thread.> + +app.ptr = <could not resolve type> +(bool) app.foobar = +``` + +You can consult the source code for those changes +[here]( + +## What is next? + +I plan to extend type name dumping to the rest of the built-in type kinds by +mapping constant names to the kind enumeration. I also plan to hopefully have +some output about `app.foobar` value. For that, I'm going to investigate the +missing dependency and implement the missing logic. If that is successful, I +will extend it to the rest of the built-in types. + +Read about the [previous week](../d-saoc-2021-13/).