digitalmars.D - SAOC LLDB D integration: 14th Weekly Update
- =?UTF-8?B?THXDrXM=?= Ferreira (158/158) Dec 23 2021 Hi D community!
- russhy (4/4) Dec 23 2021 Glad to hear that you recovered from COVID!
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (5/10) Dec 23 2021 Thanks!
- ClapTrap (5/17) Dec 24 2021 Glad you're feeling better!
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (6/25) Dec 24 2021 Glad you liked it :)
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 :)
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](https://github.com/dlang/dmd/pull/13287)), 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.
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:
- https://reviews.llvm.org/D116136
- https://reviews.llvm.org/D116138
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](https://reviews.llvm.org/D112564)), so I amended it
and added the
requested tests to be ready to merge.
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.
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) app.bar = <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](https://github.com/devtty63/llvm-project/tree/lldb-d/implement-typesystem-d).
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.
You can also read this on my blog,
[here](https://lsferreira.net/posts/d-saoc-2021-14/).
Dec 23 2021
Glad to hear that you recovered from COVID! And thanks a lot for continuing the work on LLDB integration, having great debugging capabilities is very important, the work is insane, thanks!
Dec 23 2021
=?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> On Thu, 2021-12-23 at 23:00 +0000, russhy via Digitalmars-d wrote:Glad to hear that you recovered from COVID! =20 And thanks a lot for continuing the work on LLDB integration,=20 having great debugging capabilities is very important, the work=20 is insane, thanks!Thanks! --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Dec 23 2021
On Thursday, 23 December 2021 at 21:32:56 UTC, Luís Ferreira wrote: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 :)Glad you're feeling better! Great work! And your reports are excellent, they really communicate well what you're doing and why.
Dec 24 2021
On Fri, 2021-12-24 at 10:49 +0000, ClapTrap via Digitalmars-d wrote:On Thursday, 23 December 2021 at 21:32:56 UTC, Lu=C3=ADs Ferreira=20 wrote:Thanks!Hi D community! =20 I'm here again, to describe what I've done during the=20 fourteenth week of Symmetry Autumn of Code. Updates on my COVID situation: I=20 successfully recovered from it, just feel some tiredness and lack of energy=20 sometimes, but other than that, dry cough is now occasional and I already=20 recovered from the other symptoms such as lack of smell and taste, and fever.=20 Nothing to worry, from now on :)=20 Glad you're feeling better!Great work! And your reports are excellent, they really=20 communicate well what you're doing and why.Glad you liked it :) --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Dec 24 2021