commit fe9f044c621ec6956744891a4a8d7f128b0f4788
parent 2609773618f3c434879b04ae53735bab47c0d95c
Author: Luís Ferreira <contact@lsferreira.net>
Date: Thu, 28 Oct 2021 02:01:49 +0100
posts: Add 'SAOC LLDB D integration: 6th Weekly Update'
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
Diffstat:
2 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/content/posts/d-saoc-2021-05.md b/content/posts/d-saoc-2021-05.md
@@ -87,4 +87,5 @@ on the LLDB integration, since that is what the milestone is focused on. I'm
going to clean up the idea I have of the language plugin and hopefully show
some interesting practical results.
-Read about the [previous week](../d-saoc-2021-04/).
+Read about the [previous week](../d-saoc-2021-04/) and [next
+week](../d-saoc-2021-05/).
diff --git a/content/posts/d-saoc-2021-06.md b/content/posts/d-saoc-2021-06.md
@@ -0,0 +1,140 @@
+---
+title: 'SAOC LLDB D integration: 6th Weekly Update'
+date: '2021-10-28T00:38:00+01:00'
+tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf']
+description: "This post describes what I've done on the 6th week of the
+Symmetry Autumn of Code 2021, including follow up on LLVM patches,
+implementation of the array and string slices formatters on the D language
+plugin and minor fixes and refactoring"
+---
+
+Hi D community!
+
+I'm here again, to describe what I've done during the sixth week of Symmetry
+Autumn of Code.
+
+## LLVM Patches follow up
+
+The first two patches were merged into the LLVM tree!
+
+- https://reviews.llvm.org/D111947
+- https://reviews.llvm.org/D111948
+
+Hopefully we can now proceed with merging the demangling patches as the next
+step.
+
+## LLDB D Plugin
+
+This week I primarily worked on getting the D plugin working. I added two
+features to the plugin which includes handling D slices generically and the
+special case of string slices. They are now formatted as a D string literal,
+depending on its encoding.
+
+This is a reduced example of what the LLDB can show to the user, with the D
+plugin.
+
+```
+* thread #1, name = 'app', stop reason = signal SIGSEGV: invalid address (fault address: 0xdeadbeef)
+ frame #0: 0x0000555555555edc app`app.foobar(p=0x00000000deadbeef, a=([0] = 1, [1] = 2, [2] = 3), ...) at app.d:43:2
+ 40 immutable(dchar)[] sh = "double atum"d.dup;
+ 41 const(wchar)[] si = "wide atum"w.dup;
+ 42
+-> 43 return *p;
+ 44 }
+ 45
+ 46 class CFoo {
+(lldb) fr v
+(int *) p = 0x00000000deadbeef
+(int[]) a = ([0] = 1, [1] = 2, [2] = 3)
+(long double) c = 123.122999999999999998
+(Foo) f = {}
+(string) sa = "atum"
+(wstring) sb = "wide atum"w
+(dstring) sc = "double atum"d
+(char[]) sd = "atum"
+(dchar[]) se = "double atum"d
+(wchar[]) sf = "wide atum"w
+(const(char)[]) sg = "atum"
+(dstring) sh = "double atum"d
+(const(wchar)[]) si = "wide atum"w
+```
+
+If you are excited to test it by yourself, checkout
+[this](https://github.com/ljmf00/llvm-project/commits/llvm-plugin-d) branch and
+compile lldb. I suggest the following steps:
+
+```bash
+# To use clang to compiler LLVM
+export CC=clang
+export CXX=clang++
+
+# CMake flags (compile to different target if you are not using x86)
+cmake -S llvm -B build -G Ninja \
+ -DLLVM_ENABLE_PROJECTS="clang;lldb" \
+ -DCMAKE_BUILD_TYPE=Debug \
+ -DLLDB_EXPORT_ALL_SYMBOLS=OFF \
+ -DLLVM_OPTIMIZED_TABLEGEN=ON \
+ -DLLVM_ENABLE_ASSERTIONS=ON \
+ -DLLDB_ENABLE_PYTHON=ON \
+ -DLLVM_TARGETS_TO_BUILD="X86" \
+ -DLLVM_CCACHE_BUILD=ON \
+ -DLLVM_LINK_LLVM_DYLIB=ON \
+ -DCLANG_LINK_CLANG_DYLIB=ON
+
+ninja -C build lldb lldb-server
+ldc2 -g app.d
+./build/bin/lldb app
+```
+
+You can also use
+[this](https://gist.github.com/ljmf00/a35da0e41c3a2074d74960e981f43ca6) file,
+which is what I use to test the D plugin and used to show the above example.
+
+### Issues
+
+During the plugin development and testing, I found out that LLDB was not
+properly showing UTF8 strings when using `char8_t` types with different names
+so I made a patch to fix it: https://reviews.llvm.org/D112564 . An issue was
+also created to cross reference the fix
+https://bugs.llvm.org/show_bug.cgi?id=52324 . This is particularly an issue for
+the D formatter if the compiler exports types with different type names, which
+they should. Debuggers should be able to read encoding DWARF tags and rely on
+that first, instead of hardcoding the formatters. LLDB does that but this
+somehow got skipped on https://reviews.llvm.org/D66447 .
+
+While reading how plugin are built with their internal C++ interface, I found
+very repetitive code and decide to patch it: https://reviews.llvm.org/D112658 .
+
+I also happened to reproduce
+[this](https://bugs.llvm.org/show_bug.cgi?id=45856) issue that Mathias reported
+a while ago and decided to investigate on it since it indirectly affects the
+behaviour on D side. I got some conclusions and I believe this is a regression
+introduced in 2015. Please read the issue for more context.
+
+I found other issues on the LDC side and DMD side that I already added to my
+task list, including:
+- DMD should use wchar and dchar type names instead of `wchar_t`: This triggers
+ the hardcoded formatters to format char pointers wrongly. Furthermore this is
+ wrongly typed since `wchar_t` is not exactly UTF16, according to the C
+ standard.
+- DMD also reports other types as C style naming instead of D style
+- LDC reports hardcoded const(char) type instead of a DWARF type modifier
+
+### Mailing list announcement
+
+As discussed erlier in a LLDB bug, I decided to write to the `llvm-dev` and
+`lldb-dev` mailing list to discuss about upstreaming the D language plugin. You
+can follow up the thread
+[here](https://lists.llvm.org/pipermail/lldb-dev/2021-October/017101.html).
+
+## What is next?
+
+Next week, I'm going to try to fix the above listed issues on either DMD and
+LDC trees. I need to be careful with these changes to make sure I don't break
+GDB behaviour, if they are relying on the hardcoded types. If that is the case
+I'll try to patch it too. I'm going to also finish my DWARF refactor on the
+backend to handle DWARF abbreviations correctly. The objective of the second
+milestone is finished but I'm going to try to study more features to improve
+pretty printing.
+
+Read about the [previous week](../d-saoc-2021-05/).
