git

My personal website source code
Log | Files | Refs | Submodules | README | LICENSE

d-saoc-2021-08.md (5735B)


      1 ---
      2 title: 'SAOC LLDB D integration: 8th Weekly Update'
      3 date: '2021-11-11T15:00:00+01:00'
      4 tags: ['saoc', 'saoc2021', 'dlang', 'llvm', 'lldb', 'debug', 'debugging', 'dwarf']
      5 description: "This post describes what I've done on the 8th week of the
      6 Symmetry Autumn of Code 2021, including follow up updates on the LLVM patches,
      7 some bug hunting, various fixes, LLVM ustream support of immutable type
      8 qualifier and D calling convention issue."
      9 ---
     10 
     11 Hi D community!
     12 
     13 I'm here again, to describe what I've done during the eighth week of Symmetry
     14 Autumn of Code. Sorry for being a bit late.
     15 
     16 ## LLVM upstream follow up update
     17 
     18 The following patches got merged:
     19 - https://reviews.llvm.org/D111414
     20 - https://reviews.llvm.org/D111432
     21 - https://reviews.llvm.org/D110578
     22 
     23 This includes the most important patch of the Milestone 1, which is initial
     24 support for D demangling. After a conversation with Chris Lattner (LLVM lead
     25 developer and creator) I managed to get acceptance on merging that change,
     26 leaving relicensing issues aside from my task list. This also means that
     27 minimal support for D in LLDB is now on the official tree.
     28 
     29 Right after the merge, I submitted a patch to Google OSS Fuzz, to start fuzzing
     30 D demangler: https://github.com/google/oss-fuzz/pull/6811 . Some more patches
     31 are maybe required, since the last docker is really out-of-date and is using
     32 deprecated features of the LLVM build system.
     33 
     34 ## Fixed issues and bug hunting
     35 
     36 ### Types with wrong exported names in DWARF
     37 
     38 As reported in the previous week, I pushed a fix for [issue
     39 22469](https://issues.dlang.org/show_bug.cgi?id=22469) this week, in which you
     40 can find [here](https://github.com/dlang/dmd/pull/13274). I also fixed a nit
     41 specification issue, https://github.com/dlang/dlang.org/pull/3119 .
     42 
     43 So TL;DR, now debug info with DMD should report the following type names
     44 instead:
     45 
     46 ```
     47 wchar_t -> wchar
     48 long double -> real
     49 _Bool -> bool
     50 long long -> long
     51 uint long long -> ulong
     52 imaginary float -> ifloat
     53 imaginary double -> idouble
     54 imaginary long double -> ireal
     55 complex float -> cfloat
     56 complex double -> cdouble
     57 complex long double -> creal
     58 ```
     59 
     60 ### Delegates debug info now conform with the specification on LDC
     61 
     62 This trivial change on LDC was required in order to provide the current member
     63 name, according to the specification:
     64 https://github.com/ldc-developers/ldc/pull/3866 .
     65 
     66 ### LDC should generate type qualifier tags
     67 
     68 I though that LDC issues was trivial to fix, but some required upstream
     69 support. This particular issue, is not a blocker, since only immutable tag is
     70 missing on the upstream. So, I made a collection of patches to fix that there:
     71 - https://reviews.llvm.org/D113632
     72 - https://reviews.llvm.org/D113633
     73 - https://reviews.llvm.org/D113634
     74 
     75 You can follow up this issue
     76 [here](https://github.com/ldc-developers/ldc/issues/3867) and
     77 [here](https://bugs.llvm.org/show_bug.cgi?id=52471).
     78 
     79 ### LDC should generate column DECL attributes on debug info
     80 
     81 This is also an issue that requires upstream changes. I though those changes
     82 were trivial, but apparently, they require bytecode changes. I tried to make a
     83 fix, that is half backed
     84 (https://github.com/ljmf00/llvm-project/tree/add-di-column-type) and currently
     85 freezed, due to lack of knowledge on bytecode read/write on the LLVM part. You
     86 can follow up the discussion of this issue in either LDC and LLVM bugzilla:
     87 - https://github.com/ldc-developers/ldc/issues/3865
     88 - https://bugs.llvm.org/show_bug.cgi?id=52470
     89 
     90 ## Calling convention in DMD/LDC is wrong
     91 
     92 Calling convention in D compilers is currently behaving wrong, and we need to
     93 fix this.
     94 
     95 I decided to investigate how D calling convention works, in order to thinker
     96 with calling a function on debuggers. I thought D was using the standard
     97 calling convention with additional features like hidden parameters for context
     98 pointers, but I was wrong.
     99 
    100 I tested a few things on [godbolt](https://godbolt.org/z/sWz4x37bb), and
    101 realized that the parameters are passed to the CPU registers in the reverse
    102 order. I pushed a fix on the specification, thinking that we use a custom
    103 calling convention, since LDC is also relying on this behaviour, but apparently
    104 all the implementations are not conformant and the specification is right.
    105 
    106 ### What does this means in terms of debugging?
    107 
    108 Well, with the wrong calling convention, debuggers can't reliably call
    109 functions and undefined behaviour happens, since the parameters are passed to
    110 the wrong registers. This is not a blocker for what I'm currently planning, but
    111 should definitely be fixed, in order to go forward with that feature, plus,
    112 binaries generated by different compilers can't be reliably linked.
    113 
    114 You can check the specification PR I made and appreciate discussion about that
    115 topic [here](https://github.com/dlang/dlang.org/pull/3120) .
    116 
    117 ## Other reported issues and trivial patches
    118 
    119 I also reported the following issues:
    120 
    121 - https://issues.dlang.org/show_bug.cgi?id=22492
    122 - https://issues.dlang.org/show_bug.cgi?id=22493
    123 
    124 I've made some other trivial patches not worth much attention:
    125 - https://reviews.llvm.org/D113604
    126 - https://reviews.llvm.org/D113605
    127 - https://reviews.llvm.org/D113572
    128 - https://reviews.llvm.org/D113631
    129 
    130 ## What is next?
    131 
    132 Regarding all these DWARF issues, I'm going to continue fixing some of them in
    133 parallel and probably going to start implementing the D TypeSystem and
    134 DWARFFASTParser, required for the LLDB plugin. These are things not trivial to
    135 me, but I'm going to try to have some output.
    136 
    137 You can also read this on the D programming language forum,
    138 [here](https://forum.dlang.org/thread/[email protected]),
    139 and discuss there.
    140 
    141 Read about the [previous week](../d-saoc-2021-07/) and the [next
    142 week](../d-saoc-2021-09/).