digitalmars.D - SAOC LLDB D integration: 6th Weekly Update
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (119/119) Oct 27 2021 Hi D community!
- James Blachly (2/3) Oct 28 2021 Amazing work Luís!
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (6/10) Oct 29 2021 Thanks for such motivating words =F0=9F=98=83
- WebFreak001 (8/9) Oct 29 2021 Awesome! Do you think it would be possible to add support for
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (19/31) Oct 29 2021 I'm considering using and expanding the LLVM Python API. I discussed
Hi D community! I'm here again, to describe what I've done during the sixth week of Symmetry Autumn of Code. 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. 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. ``` address (fault address: 0xdeadbeef) a=3D([0] =3D 1, [1] =3D 2, [2] =3D 3), ...) at app.d:43:2 40 immutable(dchar)[] sh =3D "double atum"d.dup; 41 const(wchar)[] si =3D "wide atum"w.dup; 42 -> 43 return *p; 44 } 45 46 class CFoo { (lldb) fr v (int *) p =3D 0x00000000deadbeef (int[]) a =3D ([0] =3D 1, [1] =3D 2, [2] =3D 3) (long double) c =3D 123.122999999999999998 (Foo) f =3D {} (string) sa =3D "atum" (wstring) sb =3D "wide atum"w (dstring) sc =3D "double atum"d (char[]) sd =3D "atum" (dchar[]) se =3D "double atum"d (wchar[]) sf =3D "wide atum"w (const(char)[]) sg =3D "atum" (dstring) sh =3D "double atum"d (const(wchar)[]) si =3D "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 export CC=3Dclang export CXX=3Dclang++ cmake -S llvm -B build -G Ninja \ -DLLVM_ENABLE_PROJECTS=3D"clang;lldb" \ -DCMAKE_BUILD_TYPE=3DDebug \ -DLLDB_EXPORT_ALL_SYMBOLS=3DOFF \ -DLLVM_OPTIMIZED_TABLEGEN=3DON \ -DLLVM_ENABLE_ASSERTIONS=3DON \ -DLLDB_ENABLE_PYTHON=3DON \ -DLLVM_TARGETS_TO_BUILD=3D"X86" \ -DLLVM_CCACHE_BUILD=3DON \ -DLLVM_LINK_LLVM_DYLIB=3DON \ -DCLANG_LINK_CLANG_DYLIB=3DON 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. 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=3D52324 . 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=3D45856) 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 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 ). 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. You can also read this on my blog, [here](https://lsferreira.net/posts/d-saoc-2021-06/). --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Oct 27 2021
On 10/27/21 9:17 PM, Luís Ferreira wrote:all sorts of amazing progressAmazing work Luís!
Oct 28 2021
=?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> On Thu, 2021-10-28 at 21:45 -0400, James Blachly via Digitalmars-d wrote:On 10/27/21 9:17 PM, Lu=C3=ADs Ferreira wrote: =C2=A0> all sorts of amazing progress =20 Amazing work Lu=C3=ADs!Thanks for such motivating words =F0=9F=98=83 --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Oct 29 2021
On Thursday, 28 October 2021 at 01:17:11 UTC, Luís Ferreira wrote:[...]Awesome! Do you think it would be possible to add support for type debugging customization like in VisualD? https://rainers.github.io/visuald/visuald/Debugging.html#customization I couldn't manage to do it with the python scripting API but maybe you can have more success with C++! Having this as standard would be nice guideline for library authors to add to their projects.
Oct 29 2021
On Fri, 2021-10-29 at 15:14 +0000, WebFreak001 via Digitalmars-d wrote:On Thursday, 28 October 2021 at 01:17:11 UTC, Lu=C3=ADs Ferreira wrote:I'm considering using and expanding the LLVM Python API. I discussed this with an LLDB maintainer, and some things on the public LLDB Python API are missing. One major thing is handling custom expressions. I though about other things like fancy syntax highlighting. Both things are willing to be accepted, we just need to make a good API for it. The reason why I'm really considering the Python API is the fact that D plugin may not be upstreamed, plus it is way easier to write synthetic frontends and summary formatters. About that debugging customizations: I don't have much knowledge on how to call methods in the debugger, but it is something I will consider exploring. Although I don't see how I can differenciate `__debugOverview` and `__debugExpanded` in the LLDB interface. Is there anything on GDB for this or any real world example I can base on? Also, note that I don't use Windows nor have it installed, so I can't test it on VisualD, if strictly needed. --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net[...]=20 Awesome! Do you think it would be possible to add support for=20 type debugging customization like in VisualD?=20 https://rainers.github.io/visuald/visuald/Debugging.html#customization =20 I couldn't manage to do it with the python scripting API but=20 maybe you can have more success with C++! =20 Having this as standard would be nice guideline for library=20 authors to add to their projects.
Oct 29 2021