llvm dev - Nov 2021 - [lldb-dev] Upstream an LLDB language plugin for D and support of custom expressions

Hi llvm-dev,

I'm writing here to discuss the addition of D language plugin to LLDB.
Following the issue #52223 from Bugzilla, we are currently using C/C++
language plugin for D. This project is part of the Symmetry Autumn of
Code 2021, which proposes to implement better integration for D into
LLDB.

This project is a highly requested feature for D developers who use
Apple-based devices since configuring GDB requires extra configuration
and self signing binaries.

One possible solution is to write a plugin using the Python public API,
although it has some limitations, since, AFAIK, custom expressions are
not currently well supported.

More context about the project milestones can be found
[here](lsferreira.net/public/assets/posts/d-saoc-2021-
01/milestones.md).

I would like to discuss the possibility of upstreaming the plugin in
C++ to the official tree and if there is anything in the roadmap to
support custom expressions via Python.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211025/517d2aa9/attachment.sig>

+lldb-dev

On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi llvm-dev,
>
> I'm writing here to discuss the addition of D language plugin to LLDB.
> Following the issue #52223 from Bugzilla, we are currently using C/C++
> language plugin for D. This project is part of the Symmetry Autumn of
> Code 2021, which proposes to implement better integration for D into
> LLDB.
>
> This project is a highly requested feature for D developers who use
> Apple-based devices since configuring GDB requires extra configuration
> and self signing binaries.
>
> One possible solution is to write a plugin using the Python public API,
> although it has some limitations, since, AFAIK, custom expressions are
> not currently well supported.
>
> More context about the project milestones can be found
> [here](lsferreira.net/public/assets/posts/d-saoc-2021-
> 01/milestones.md).
>
> I would like to discuss the possibility of upstreaming the plugin in
> C++ to the official tree and if there is anything in the roadmap to
> support custom expressions via Python.
>
> --
> Sincerely,
> Luís Ferreira @ lsferreira.net
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211025/43022c85/attachment.html>

I think having more language plugins in LLDB is in general a good
thing. Given the past experience with other plugins (that have been
since removed) there are probably a few things that should be
clarified before we merge new plugins:

1. Who is going to maintain it?

In the past we had to remove the Go plugin because we couldn't find a
single person on this planet that wanted to maintain it after the
original author stopped working on it. It would be good to have some
confidence that the plugin doesn't end up without a maintainer in the
near future. Having multiple people involved seems like a good way to
show that this isn't likely to happen. I think having another person
reviewing the patches and being willing to maintain the code seems
also fine IMHO.

2. How is it going to be tested?

The most straightforward way of testing seems to be to just have some
D sources checked in, we call the D compiler to compile them and then
have a normal API test that tests the language-specific parts. But
that also means we would have a dependency on the D compiler to run
the tests which makes maintaining LLDB overall harder. We currently
get away with this approach for C/C++/Obj-C because we have a compiler
for those languages in LLVM itself.

The other solution would be to check in some pre-generated YAML'ified
debug info similar to what we are currently doing in some shell tests.
That means we don't have a dependency on the D compiler to run the
test suite, but those pregenerated tests have a tendency to be hard to
maintain (some existing tests require me to change my local username,
run macOS/Xcode and do a bunch of manual cleanup to end up with the
same output). Also they often clutter the repository with random
strings that show up in grep (I'm pretty sure we have at least one
test that contains the Google-internal network proxy config or
something similar). I think we can get something maintainable with
some simple script that can post-process whatever the D compiler
emits. Requiring people to install the D compiler to regenerate the
tests is IMHO a reasonable requirement as that rarely happens.

3. How is this going to be implemented?

Bit of a broad topic, but it would be good to know what's the general
plan for implementing the plugin. From what I can see we need at least
a DWARF parser, a lldb_private::Language-based plugin and a
TypeSystem-based plugin. I believe that's enough to get most of the
functionality in LLDB working (the only exception is the expression
parser), but there's a good chance I forgot something in that list.
The expression evaluator will probably be a whole topic on its own,
but I would expect it to be some small evaluator for simple D
expressions (+ maybe something relying on the Clang expression
evaluator for things like function calls, etc.).

Regarding the custom expression: I don't think there are any plans in
that direction, but I think having support for hooking in custom
expression evaluators seems like a reasonable idea.

- Raphael

Am Mo., 25. Okt. 2021 um 18:50 Uhr schrieb David Blaikie via lldb-dev
<lldb-dev at lists.llvm.org>:
>
> +lldb-dev
>
> On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Hi llvm-dev,
>>
>> I'm writing here to discuss the addition of D language plugin to
LLDB.
>> Following the issue #52223 from Bugzilla, we are currently using C/C++
>> language plugin for D. This project is part of the Symmetry Autumn of
>> Code 2021, which proposes to implement better integration for D into
>> LLDB.
>>
>> This project is a highly requested feature for D developers who use
>> Apple-based devices since configuring GDB requires extra configuration
>> and self signing binaries.
>>
>> One possible solution is to write a plugin using the Python public API,
>> although it has some limitations, since, AFAIK, custom expressions are
>> not currently well supported.
>>
>> More context about the project milestones can be found
>> [here](lsferreira.net/public/assets/posts/d-saoc-2021-
>> 01/milestones.md).
>>
>> I would like to discuss the possibility of upstreaming the plugin in
>> C++ to the official tree and if there is anything in the roadmap to
>> support custom expressions via Python.
>>
>> --
>> Sincerely,
>> Luís Ferreira @ lsferreira.net
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev