Hi D community!
I’m here again, to describe what I’ve done during the eighth week of Symmetry Autumn of Code. Sorry for being a bit late.
LLVM upstream follow up update
The following patches got merged:
This includes the most important patch of the Milestone 1, which is initial support for D demangling. After a conversation with Chris Lattner (LLVM lead developer and creator) I managed to get acceptance on merging that change, leaving relicensing issues aside from my task list. This also means that minimal support for D in LLDB is now on the official tree.
Right after the merge, I submitted a patch to Google OSS Fuzz, to start fuzzing D demangler: https://github.com/google/oss-fuzz/pull/6811 . Some more patches are maybe required, since the last docker is really out-of-date and is using deprecated features of the LLVM build system.
Fixed issues and bug hunting
Types with wrong exported names in DWARF
As reported in the previous week, I pushed a fix for issue 22469 this week, in which you can find here. I also fixed a nit specification issue, https://github.com/dlang/dlang.org/pull/3119 .
So TL;DR, now debug info with DMD should report the following type names instead:
wchar_t -> wchar long double -> real _Bool -> bool long long -> long uint long long -> ulong imaginary float -> ifloat imaginary double -> idouble imaginary long double -> ireal complex float -> cfloat complex double -> cdouble complex long double -> creal
Delegates debug info now conform with the specification on LDC
This trivial change on LDC was required in order to provide the current member name, according to the specification: https://github.com/ldc-developers/ldc/pull/3866 .
LDC should generate type qualifier tags
I though that LDC issues was trivial to fix, but some required upstream support. This particular issue, is not a blocker, since only immutable tag is missing on the upstream. So, I made a collection of patches to fix that there:
You can follow up this issue here and here.
LDC should generate column DECL attributes on debug info
This is also an issue that requires upstream changes. I though those changes were trivial, but apparently, they require bytecode changes. I tried to make a fix, that is half backed (https://github.com/ljmf00/llvm-project/tree/add-di-column-type) and currently freezed, due to lack of knowledge on bytecode read/write on the LLVM part. You can follow up the discussion of this issue in either LDC and LLVM bugzilla:
Calling convention in DMD/LDC is wrong
Calling convention in D compilers is currently behaving wrong, and we need to fix this.
I decided to investigate how D calling convention works, in order to thinker with calling a function on debuggers. I thought D was using the standard calling convention with additional features like hidden parameters for context pointers, but I was wrong.
I tested a few things on godbolt, and realized that the parameters are passed to the CPU registers in the reverse order. I pushed a fix on the specification, thinking that we use a custom calling convention, since LDC is also relying on this behaviour, but apparently all the implementations are not conformant and the specification is right.
What does this means in terms of debugging?
Well, with the wrong calling convention, debuggers can’t reliably call functions and undefined behaviour happens, since the parameters are passed to the wrong registers. This is not a blocker for what I’m currently planning, but should definitely be fixed, in order to go forward with that feature, plus, binaries generated by different compilers can’t be reliably linked.
You can check the specification PR I made and appreciate discussion about that topic here .
Other reported issues and trivial patches
I also reported the following issues:
I’ve made some other trivial patches not worth much attention:
What is next?
Regarding all these DWARF issues, I’m going to continue fixing some of them in parallel and probably going to start implementing the D TypeSystem and DWARFFASTParser, required for the LLDB plugin. These are things not trivial to me, but I’m going to try to have some output.
You can also read this on the D programming language forum, here, and discuss there.
Read about the previous week and the next week.